when is Xojo.get available?

started a subclass of the webSegmentedControl this morning so that I could add setting help tags to the individual segments rather than just the entire control more like the desktop version. This does involve using execute javascript to set the .title property of the individual children in the Xojo control and so is really not recommended :wink: But if it breaks in the future I will suck it up and fix it as I can’t be mad when they tell you not to do something and you do it anyway :wink: Thats besides the point though, I started a new project for easier testing of the individual control and as a test just implemented a segmentHelp method something like:

[code]function segmentHelp( index as integer, assigns s as string)

ExecuteJavaScript( "Xojo.get('" + Me.ControlID + "').children[" + Str( index) + "].title='" + s + "';”)

[/code]
which, in this otherwise empty project results in a javascript error because Xojo.get doesn’t exist.

Could not execute returned javascript: Xojo.get is not a function. (In 'Xojo.get('l1BHQzge')', 'Xojo.get' is undefined) Source: Xojo.get('l1BHQzge').children[0].title='help tag for segment one';
This happens if I do the setting in the shown event or if I do it later in the action event of another button on the page, so it’s not just a matter of things not being loaded yet or something like that. If I change it to document.getElementById() then it works fine, but I’m concerned that Xojo.get might only get included in the framework if the page you’re using it on has a web api control on it? Or perhaps some other control that requires it? And isn’t always available.

In this app my pages are dynamic and might not include any webAPI controls depending on what controls the user chooses to put on the page and so this might not be in the framework while they are working on their interfaces. Is it correct that anyplace I’m currently using Xojo.get outside of a WebAPI control I should instead use the document.getElementByID() instead just in case Xojo.get isn’t loaded in the framework for the page?

Or is this not on purpose and I should file a bug report?

Either way it’s a gotcha that you should know about if you’re diving into the javascript at all outside of the WebAPI.

Well the way the WebAPI PDF read was that Xojo.get was just a synonym for document.getElementById so if you’re having trouble with it, there’s nothing wrong with using document.getElementById

My guess is that someone writing the framework simply got tired of continually writing document.getElementById and made a shortcut.

Thats exactly what it is :slight_smile: You can see it in the framework if it’s loaded. It’s just a call to getElementById as you suspect. And my work around IS to do that. My concern is that the documentation for it does not suggest that it isn’t always there, and if you load interfaces dynamically the way I do you may have situations where there are no plugin controls on a page and therefore it won’t be available as that doesn’t seem to be sent as part of the framework unless it’s needed.

There’s nothing wrong with that exactly, just that it needs to be known and documented or people will use the one that the WebAPI suggests and potentially have users run into trouble that they might not find in testing.

[quote=338446:@James Sentman]Thats exactly what it is :slight_smile: You can see it in the framework if it’s loaded. It’s just a call to getElementById as you suspect. And my work around IS to do that. My concern is that the documentation for it does not suggest that it isn’t always there, and if you load interfaces dynamically the way I do you may have situations where there are no plugin controls on a page and therefore it won’t be available as that doesn’t seem to be sent as part of the framework unless it’s needed.

There’s nothing wrong with that exactly, just that it needs to be known and documented or people will use the one that the WebAPI suggests and potentially have users run into trouble that they might not find in testing.[/quote]
Some of the methods are only available when you actually create a subclass of WebControlWrapper.

Just to be clear… Calling into methods that are not documented in the WebSDK docs is dangerous. We periodically do maintenance on the framework and sometimes things get renamed or moved around.

I am not calling any method in the framework not documented in the WebSDK. I just was surprised that xojo.get wasn’t there if there wasn’t a webSDK control on the page thats all.

I AM adding a .title property on the children of the control which I do understand is not proper usage and that you might change the structure of the control and break my hack at any moment. I accept that and if it breaks I’ll either figure it out again or write a completely separate control for it. This is a danger I’m aware of and will not bother you with if it happens, the lack of Xojo.get was not one I was aware of.

The whole web framework works that way. If you don’t have a web listbox, the JavaScript for the control doesn’t get sent to the browser.