I’m using the WebSDK. In the SetupCSS event, I want to manipulate the assigned WebStyle in the Style property. This is the code:
[code]Sub SetupCSS(ByRef Styles() as WebControlCSS)
IF ME.Style <> NIL THEN
DIM myStyle() AS WebControlCSS = WebControlCSS.Convert(ME.Style)
FOR EACH CSSstyle AS WebControlCSS IN myStyle
DIM Properties() AS String = CSSStyle.PropertyNames //shown as NIL in the debugger (for whatever reason nil, it's an array of strings after all...)
DIM content AS String = CSSstyle.StringValue //shows the entire css class in the debugger
//Do some stuff here
Styles.Append CSSstyle
NEXT
END IF
End Sub
[/code]
However, the array Properties() is always empty, even though the debugger clearly shows that the WebControlCSS variable does have contents. What am I doing wrong?
Well, the fact that WebControlCSS.PropertyNames returns an empty array when it is supposed to return the property names has nothing to do with style manipulation so far.
Even more so as I can iterate through ProperyName(idx) using Count. And I can even change the contents using Value(PropertyName), so manipulation is possible after all. Either I’m not getting the overall concept or I just discovered bug #9 in the web framework today but I’m not complaining about that as those bugs helped me to work around another nasty one.
Btw: not being able to manipulate a user assigned style is a bad idea IMHO; some style properties might simly not make sense to some controls.
[quote=219519:@Alex von Siebenthal]Well, the fact that WebControlCSS.PropertyNames returns an empty array when it is supposed to return the property names has nothing to do with style manipulation so far.
Even more so as I can iterate through ProperyName(idx) using Count. And I can even change the contents using Value(PropertyName), so manipulation is possible after all. Either I’m not getting the overall concept or I just discovered bug #9 in the web framework today but I’m not complaining about that as those bugs helped me to work around another nasty one.
[/quote]
Ok. I’ve just reviewed the code, so I can give you a little insight.
First of all, WebControlCSS uses a Dictionary to store its data. The PropertyNames method just iterates over each of the keys and returns them to you. If you’re getting an empty array, the backing dictionary must not have any items in it.
I’d still like to see a sample from you that fails. Looking at this code, I still don’t see why this would be failing.
So at least being able to decide if a style is sent to the browser is designed behaviour. However, three comments on that:
Item zero does not contain the style from the control’s .Style property, but only the coordinates and size in the inspector
I cannot only remove the item, but I can manipulate the style before it is sent to the browser (which is a good thing in my opinion). According to your statement above that should not be the case. Maybe I am just confusing things at this point…
To add another (potential) bug here: The .Style property should be hidden for tray-only controls (according to the docs), but it isn’t. However, that (potential) bug helped me to get around another bug (https://forum.xojo.com/26540-strange-toolbar-behaviour). To work around that, I created a custom control (tray only) where I can assign a style in the inspector which is then manipulated by adding “!important” to its properties. I know it’s not a “supported” hack but I suppose it’s the most proper way to get around the style conflicts raised in the thread without hacking into JS and alike. That control can be found here: https://dl.dropboxusercontent.com/u/106712747/ToolBarProblems2.xojo_binary_project
That’s what I guessed it’s supposed to do - which is why I am a bit irritated that the PropertyNames method returns an empty array while the dictionary does have contents.
I want to emphasise that I appreciate your efforts and it’s not my intention to discredit anyone! If I sound offensive it might be a matter of language barriers
Please put your sample project into a Feedback case. It’ll be a lot easier to track that way. Saying something here on the forum is not the same and doesn’t push reported bugs through our Q/A process.
True. Index zero is just base style info, like coordinates.
True, but the only reason you should be manipulating the coordinates is if your control represents itself differently than the coordinates supplied for some reason.
You do this yourself by adding a constant to your control called TrayOnly with a value of True which should hide the Style property.
Okay, it seems that this is a misunderstanding from my side. I wasn’t talking about manipulating index zero or the coordinates but any WebStyle, particularly the one assigned to the .Style property and its properties like background color, borders etc.
That’s what I did - and the Style property still shows (see example). It’s all in the feedback case linked above.
Ok. I’ve verified the PropertyNames bug. Do me a favor though… file each bug separately. Our system is really not designed for fixing multiple bugs under one case. I’ve renamed 41114 to be just the PropertyNames case.