Thanks for the suggestion. Indeed, if I place html code containing a full with javascripts and a with onload event to a javascript method in a HTML_AREA field, Servoy will add that code in the final html page in WebClient viry nice, the headed content in the header and the body the same. It will also will create a Wicket load event for the onload event from my initial that is written in that HTML_AREA field.
So far, so good! I manage to insert the calendar and it works OK, BUT, only when the form where it’s embedded is displayed first time. If I do any reloading of the foundset, or leave the current form and display it again, or any action that will end in Servoy changing the html in WebClient, that content generated by the calendar’s javascripts in some
s that it use will be removed from there. The
s will still be there, but with no content.
Also regarding the WebClientUtils plugin, it works fine with one exception so far. When I call plugins.WebClientUtils.executeClientSideJS(js_code); on the onShow method of the form, the js_code gets executed in the browser only when the onShow is called for the first time. That is when the form is first displayed. Any further calls will not execute the js_code in the browser. If I call it on another event, let’s say on a button click, it will execute, but not if the call comes from onShow. Even a simple plugins.WebClientUtils.executeClientSideJS(“alert(‘Hello’);”); will not work.
Hope you have other suggestions as well! I really need to get this works. I didn’t found any calendar that works in the WebClient. And I think it’s easyer this way then implementing everything from scratches in servoy. That calendar is really nice.
This is how it looks for the first time:
[attachment=1]calendar1.PNG[/attachment]
Then I change that combobox selection which will reload the founset of the form. I don’t call any javascript using the WebClientUtils plugin, but after that foundset loads other data (I’m using foundset.find() …) the calendar becomes like this: (If I remove the foundset.find() and everything else the calendar will look OK, and I can even change the data from it)
[attachment=0]calendar2.PNG[/attachment]
I think I found something … Servoy reset the page with the content from the server, so anything that javascript calendar wrote there will be replaced with the initial
s which are empty of the content. This makes sense! I need to see how I can make it writes again.
But if some of you thinks at something else, please lay it here! And also that plugins.WebClientUtils.executeClientSideJS(js_code); when called in onShow, doesn’t get called in the browser. I don’t understand that.
I’m two steps behind getting this works and one of them is the plugins.WebClientUtils.addCallback that don’t call the server function. Any idea? Please I must get this run.
The addCallback generate this code in the html:
The addCallback generates a Wicket that don’t call the server.
The plugins.WebClientUtils.executeClientSideJS is not called from onShow method of the current form. (I mention about this in an earlier post)
is true, the generated Ajax call is not valid if used in onShow() or onLoad(), I have no idea right now why this is but I suspect this is deep in the Wicket API - I have no workaround for the time being.
is not true, executeClientSideJS() is called and is working (try it with a simple plugins.WebClientUtils.executeClientSideJS(“alert(‘hello world’)”); and you will see it working, but if you use a callback generated by the addCallback() then of course it won’t work, not because executeClientSideJS() is not working but because addCallback() is returning a reference to a Behavior which is not registered somehow).
plugins.WebClientUtils.executeClientSideJS works fine for me, except when it’s called from onShow. This is the method I call from onShow.
But when onShow is called for the first time, it works too. At the second call of onShow, and the other ones that follow the plugins.WebClientUtils.executeClientSideJS will not call. In reset, if I call it from the action of a button it works fine!
About plugins.WebClientUtils.addCallback, yes, I generated it on onShow or onLoad, you think it’s because of this? I’ll try to see if I can generate it on other method, though I need that script in the html page at startup.
Then it must be something with the onShow and onLoad.
I also manage to call some methods on the server from javascript. But not using plugins.WebClientUtils.addCallback. This is the code I wrote in Servoy and the Wicket that is generate in this case:
Do you have an actual example that doesn’t work? Because the snippets you posted so far aren’t consistent with eachother.
So far, none of the reported issues can be reproduced, with the exception that addCallback() doesn’t support String values as arguments. In some of the snippets you put in the thread you’re using that.
I’ve test it in a small demo solution! Yes, here a simple call using executeClientSideJS to a javascript function works well on onShow, each time onShow is called.
But addCallback still doesn’t work. Maybe I don’t use it as it should! I’ve add a button in a html code. I want to send a message to the server when it is clicked. First time when I click it I receive the request in the server. But there I want to change something in the form, which is not changed. And after this, nothing will work in the user interface. No servoy button will respond anymore!
I tested this with the latest version of the Web Client Utils plugin and it works fine.
Of course you have to make the HTMLArea of fmor “html_form” non-editable, or else you don’t even see the butotn to click, but besides that it just works.
I do not have the previous version anymore, but as far as I can see it should’ve also worked with the old version, as you’re not using a String value in the arguments array parameter for the addCallback function.
Best to try it with the latest version of the plugin and with the HTMLArea set to non-editable.
That’s strange. I do have the last version. But I’ve tested with both of them and the behavior was the same. I user Servoy Version: 5.2.0 - build 997. Should I upgrade?
I see the “Click me to call the server!” button even if the HTML_AREA field is editable. I’ve set it to non editable and the behavior is the same as I described!
Just to ask you: when you click on the “Click me to call the server!” button, apart of the alert popup that appear, does the current form in the tab_main (main_form) changes to edit_form? As it happened when you click on the “Second tab” button! This is my intention, to change the form that contains the HTML_AREA with another one, when I receive a callback from javascript.
After I click the “Click me to call the server!” any click on the other buttons does nothing, although the “Call browser” button should call a javascript and the other two should change the content of the tab panel!
Thanks a lot! I also just updated my Servoy to the latest version
Anyway I also must check the production application, because there it behaves different then the simple demo, as I described first time. So I might have something wrong there!
Hi Paul, I still didn’t fix the problem with executeClientSideJS in my solution. It seems there is something wrong with the main form of the solution, though I couldn’t figure out what until now…
I manage to find something why executeClientSideJS don’t work, but couldn’t reproduce in the simple solution I posted here. I have in almost each form, including the one with the html field, some Calendar fields. If I remove those fields or set them to disabled it works.
But I couldn’t reproduce it in the simple solution, so I’ll test it more. Do you have any idea why this might happened?
I have no idea why it would work in some scenario’s and not in others. So far in the samples I created it works and the engineers are looking at the issue in the sample you provided.
If you manage to create a reproducible case for the executeClientSideJS issue you now see, please create a case with the sample on the project on ServoyForge
I manage to reproduce both problems in a simple solution. I post 2 cases on ServoyForge. Also in the first demo I managed now to reproduce both problems without changing anything. I don’t understand how it worked last week and today it didn’t.