How to trigger a button (Action) from another control in a Web app?
In the desktop version it can be down using “push”. I don’t seem to be able to do it on a web app
don’t put the code you want executed in the ACTION event of the button.
Put it in a method and then CALL it from the ACTION event of any/all controls you wish to perform that same action
[quote=116702:@Peter Jais]How to trigger a button (Action) from another control in a Web app?
In the desktop version it can be down using “push”. I don’t seem to be able to do it on a web app[/quote]
self.ExecuteJavascript("document.getElementById('" + _
Button1.ControlID + "_inner').click();")
Thanks Dave - I tried it and it worked
Michel, I will try your suggestion as well
[quote=116712:@Peter Jais]Thanks Dave - I tried it and it worked
Michel, I will try your suggestion as well[/quote]
Dave suggestion is often preferable in pure Xojo, as it works in both Web and Desktop.
The JavaScript I provided works differently but is especially of interest as a sample of what can be achieved by adding features to Xojo Web Edition (or Xojo Cloud) that do not exist natively.
Please don’t do it this way. The layout of controls in the DOM is subject to change without notice and your app could suddenly break when a new version of the IDE is released.
You mean the ControlID property will be deprecated ?
Probably not, but certainly the “_inner” part could change.
There are better ways to do this, that won’t break if / when we alter the framework, than by poking at the framework using execute javascript
Plus there are things that will not work properly unless the user actually physically clicks the button - your javascript won’t trigger it to run
Alright.
[quote=116750:@Norman Palardy]There are better ways to do this, that won’t break if / when we alter the framework, than by poking at the framework using execute javascript
Plus there are things that will not work properly unless the user actually physically clicks the button - your javascript won’t trigger it to run[/quote]
I did test it before posting, and the Action event does fire correctly. But I will keep in mind that such JavaScript is discouraged.
Thank you Greg and Norman.
It will work - for now.
But IF the framework we’re changed & the “_inner” element changed/removed/etc your java script would no longer work.
Thats the danger of poking directly into the framework - it could change and your code would need adaptation if that happened.
And it could work in one version and not another as the underlying DOM could be different.
Hence the admonition to “not hack the framework” because such hacks can be fragile.
[quote=116780:@Norman Palardy]It will work - for now.
But IF the framework we’re changed & the “_inner” element changed/removed/etc your java script would no longer work.
Thats the danger of poking directly into the framework - it could change and your code would need adaptation if that happened.
And it could work in one version and not another as the underlying DOM could be different.
Hence the admonition to “not hack the framework” because such hacks can be fragile.[/quote]
Thou shalt not hack the framework. Noted.
What about
ExecuteJavaScript("document.getElementsByName('Button1')[0].click() ; " )The other problem with using ExecuteJavascript is that it requires a round trip to the browser. Dave’s suggestion is much better because it’s immediate and local to the server.
I understand and did write : [quote]Dave suggestion is often preferable in pure Xojo, as it works in both Web and Desktop.[/quote]
My question is less about the structure of a program than about being able to use JavaScript when it is necessary without having to worry about future potential changes in the framework. What I posted is just an example of addressing a control other than by the ID.
Xojo WE has severe limitations which often render JavaScript necessary. I used it to get the KeyDown event which is necessary to get arrow keys in Internet Explorer, for instance. More recently, topics have come up like moving controls with the mouse. I tried Xojo code and it was a catastrophe. JavaScript from Brock Nash saved the day. JavaScript is not the only technology that WE needs. Last week I did sprite sheets in pure Xojo, but they are way slower than in CSS. This time WebSDK helped a great deal by providing a wrapper.
You may have noticed that I usually favor pure Xojo solutions. But sometimes, in WE as well as desktop, Xojo limitations can only be overcome through shell, AppleScript, declares, OLE, plugins, JavaScript, CSS or other means I may have forgotten at this instant.
As for the round trip, frankly, for a simple click, I would not worry too much about bandwidth 
Many of them intentional. I don’t use WE as it doesn’t fit my needs. It’s still easier to code in jquery. (For me. Ymmv)
No tool is perfect. Each individual his own recipe for success.
@Michel Bujardet
You’re perfectly save editing the DOM if you’re doing it inside your own WebSDK Control. So for your spritesheets I wouldn’t worry about doing a pure Xojo way until they have a better solution (since its currently slower afterall). You’ll get a much better experience with your WebControl and not have to worry about deprecations and alterations Xojo makes that may alter the DOM of their built-in controls.
[quote=117243:@Brock Nash]@Michel Bujardet
You’re perfectly save editing the DOM if you’re doing it inside your own WebSDK Control. So for your spritesheets I wouldn’t worry about doing a pure Xojo way until they have a better solution (since its currently slower afterall). You’ll get a much better experience with your WebControl and not have to worry about deprecations and alterations Xojo makes that may alter the DOM of their built-in controls.[/quote]
Right. It’s editing our DOM code that can get you into trouble.
So this which refers only to the control name could be safe ? Or should it be avoided as well ?
ExecuteJavaScript("document.getElementsByName('Button1')[0].click() ; " )