ControlID Problem in WebSDKUIControl

I was doing some tests on the new WebSDKUIControl class but I didn’t understand if I found a bug or I’m doing something wrong. In the SessionJavascriptURLs event the property me.ControlID is different from the id of the created div. You can find an example here.
If you inspect the browser, the id of the div is different from what is loaded in the file TestClickCode.js in the instruction var something = document.getElementById(‘id’);

SharedClassFile1.Session = Nil

and

SharedClassFile1.Data = JSTestFile.ReplaceAll("<<var>>",me.ControlID)

are technically incompatible

Setting the session nil makes it available to all sessions. ControlID is specific to a control of a session.

You’re right, I missed it in the various tests but even if I put the reference to the session does not return the right id. In this event the session must always be nil? To load other session specific javascript code do you use ExecuteJavaScript?
If you look at the example SDK Examples the same error is made for CSS:

MyControlCSS = New WebFile
MyControlCSS.Filename = "myclass.css"
MyControlCSS.MIMEType = "text/css"
MyControlCSS.data = "#" + Self.ControlID + " { color: red }"
MyControlCSS.Session = Nil // Very important, so this file will be available to all sessions

Is there any more complete example? The ones provided by xojo in the Extra folder are too basic and for what I have to do I need a more detailed documentation about DOM management, events etc…

would like that too !

3 Likes

You’ll have to ask @Greg_O_Lone for more examples, but it would really help to ask for the things you need. You’ve listed a couple items, why not go into detail about what you’d like to know and file a ticket?

In the meantime I would like to understand why in the problem posed the right id is not returned, for the rest I am finding alternative methods. I am transporting all the web 1.0 controls without big problems. It just bothers me to write them in the way 2.0 was not thought. Unfortunately I do not understand much from the documentation… my fault.
I will open ticket when I understand if it is really a problem. I think it is right first to understand if it is only my problem and if someone can help me.

Open new ticket also for this. feedback://showreport?report_id=62979

I closed that case. Tim Parnell’s first response to you was correct. Comment out the two places where you are setting the session property to nil and things should just start to work.

Hi Greg, thanks for your answer. I tried to do what you say and it still doesn’t work. Could you give me a small example? Maybe in my example it tricks the name I gave to the “SharedClassFiles” that are not actually shared. Also because if what you say is true then also the example Xojo 2020r2\Extras\WebSDK\Examples\SDK Examples for css is wrong.

I may be boring but there is something in the logic that does not fit me …
If I call ControlID first to generate javascript code it means that the DOM of the element has already been created, doesn’t it? In this case then what does the framework do? See if there is a reference to the session and then decide to change dom or id? As far as I’m concerned you should always have a data matching integrity between Xojo and javascript properties.

Last question… Will more complete examples be provided in the next update?

If you look at the Gravatar example project, that file does use a shared file. That is, the gravatar.js file that is delivered is the same webfile for all sessions, and is the reason it is stored as a shared property.

I just checked the files that shipped with 2020r2 and they all seem to be working as designed. Keep in mind that the SDK Examples file is just an example of how to set up a websdk file and is not intended to be a complete control. When creating WebFiles for delivering your javascript classes make sure they are Shared Properties and that you only create them once (that’s why they’re wrapped in if-then statements in the examples).

In the Javascript framework, nothing exists except for a div element with the controlID in the id attribute until you render something new. You should get a reference to that element and put your control inside of it.

I appears that you’re over-thinking this. Your javascript code should not have any hard-coded references to particular controlIDs in it. The control ID is passed in to the control in its constructor and can always be accessed using the ControlID method. Once a control is created and the ID is set, it never changes. The only way I can imagine this appearing to happen is if your controls are being rapidly created and destroyed.

OK thank you very much for the explanation. I will do more tests to see what I am wrong. Surely the main problem is that I am converting all my 1.0 controls with the new framework without rewriting all the code. For now I’m loading all the js code with ExecuteJavaScript and its control id… They will be less efficient but they seem to work. When there will be more complete examples I will rewrite them a bit at a time and integrate all the event/property management in the XojoWeb.XojoVisualControl class.

Boh, I still do not understand. I enclose a video to make you understand what I mean. I commented the line in which I set the session to nil as you wrote me at the end of the feedback, but it still does not work.

In debug it gives me the id “pFDVw5” while if you check the browser gives me “r1nP3x”.