WebControlCSS.PropertyNames fails?

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?

Nothing. You can’t manipulate the user assigned style.

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 :slight_smile: 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.

As the developer of the control, you decide whether that style is sent to the browser. It’s just an array after all, so you could remove item zero.

Code review revealed this to be false.

If you file a bug report, I can certainly take a look.

[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 :slight_smile: 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.

That puzzled me at first, but then:

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.

Here’s an example project that should include all the points raised above: https://dl.dropboxusercontent.com/u/106712747/ExampleWebControlCSSBugs.xojo_binary_project
I tried to comment it as extensively as possible.
Of course I will report all the bugs encountered. Maybe some aren’t bugs but the behaviour I expect is not what is the intended behaviour.

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 :slight_smile:

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.

Looked back at the code/docs… Edited above…

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.

Sure :slight_smile: <https://xojo.com/issue/41114>

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.

Awesome! Happy debugging :slight_smile:

<https://xojo.com/issue/41114>
<https://xojo.com/issue/41115>
<https://xojo.com/issue/41116>
<https://xojo.com/issue/41123>
<https://xojo.com/issue/40410>

41116 is really driving me crazy
I think I do have some more bugs noted somewhere, let me see.