Many months ago i asked in the forum how to implement CSS pseudo class that can make
a container control change upon hoover and also to make a container control blink using
CSS. A friend helped me to do this and i would like to share the code here:
Create a container control. Set the background to blue. Put a WebLabel in the container control. Set the text label to white. Name it ccBlinkingLabel
Create an instance of the control in your webpage.
In the Opening event of your webpage, put the codes below:
The Opening event is too early, the control may not have reached the browser yet. You cannot ExecuteJavaScript on controls until the Shown event. This may work locally but is likely to fail in production.
Another downfall is that the framework can (and will) re-render the object in the browser under certain conditions, and the classname “blinking” will be lost. It’ll just stop blinking and you won’t know why until you look at the DOM in the inspector and discover it’s missing. That’s why I recommend building custom WebSDK components if you find yourself modifying page elements using JavaScript.
You could implement an observer to catch when it’s re-rendered and reapply your changes, but it’s more JavaScript so you might as well create your own control.
you can indicate that you are pasting code by using the code option on the toolbar (that looks like this </>) or using 3 back ticks before and after your code (```) on a separate line.
The above is just for ideas and testing
You can modify it and make variations.
But i am happy as it is now seems easy to make CSS pseudo class selectors, at least for me.
So i would like to share it with the rest.
I modify it to do things like below
allowing the user to select when to start blinking and when to stop
Very good if you want to attract user attention to SCADA widgets.
I thought with Web2 the Open event was usable and preferable in almost all cases.
However, in the documentation (from your link) I read a statement I thought was no longer valid: “In most cases, you should use the Shown event to initialize controls”.
so I ask:
why not always just use the Shown event?
what is the advantage (or need) of using both or choosing the Opening or Shown event from time to time?
otherwise, is it just an unnecessary (or superfluous) complication that creates more confusion than anything else?
Because the Shown event will be raised anytime the control is shown, not just the first time. So if you hide the page then show it again, the event is raised again for the page and every control on it. When Shown is raised, that may indicate the control has been re-rendered in the browser but there may be other conditions under which the control will be re-rendered where events are not raised.
what is the advantage (or need) of using both or choosing the Opening or Shown event from time to time?
Opening says the control has been created and is ready on the Xojo side, Shown says the control is visible in the browser on the client-side. That’s probably the best way to look at it.
otherwise, is it just an unnecessary (or superfluous) complication that creates more confusion than anything else?
It has its uses, and the ones in this thread aren’t awful, you just need to be aware that you might not be able to rely on what you do in the Shown event (if you’re modifying the client-side DOM) being retained at all times. If the framework re-renders the control and your changes are lost, that’s not a framework bug.
