iSeller Commerce
iSeller POS Retail
iSeller POS F&B
iSeller POS Express
Crosslight
WebUI
ClientUI
What's New
Download Trial
Web Solution
Mobile Solution
Enterprise Solution
Custom Development
Blog
Community
Latest Development Blogs
ForumPostTopic
Browse By Tag
This sample demonstrates a problem with a webButton in a table and the action of webCallOuts when the target is a WebButton.
Before clicking Execute click Button1 and Button 2 to see that they work and that the webCallOuts are displayed. WebCallOuts for Button1 and Button2 are in Grp1 and the webCallOut for Execute is in Grp2.
Note that if the webCallOut is displayed clicking the button doesn't close the webCallOut. This will be bothersome to users. I suggest that when the target is a WebButton that the WebCallOut close. Otherwise, developers will have to write a script to close it. At least there should be a property to allow this action.
Start over.
Get webCallOut for button1 to display. Now click Execute. Row 1 of the table is hidden. WebCallOut for button1 is now pointing to Button2 since it didn't close. The target is not visible but the WebCallOut is still visible. Not good. Close the webCallOut. Click Button2. Nothing happens. Why?
Click Execute again and Button1 appears but doesn't work.
Here is the link the the nightly build, WebDesktop and WebUI Framework.
As with the usual nightly build, this build is intended for testing purpose only in order to verify the issue you reported has been corrected. Some issue and instability should be expected in using nightly build.
Regarding automatic closing of WebCallOut if the target is WebButton, the operation must be done manually since WebCallout currently do not have a event listener for the target control.
You will also need to manually handle the WebCallOut closing on execute button click for the same reason.
Regarding the click event handler is missing after hiding table1, it seems this issue is caused by a bug. A bug report has been submitted for this issue. The bug report is work item #585 which is related to issue reported in this thread.
Let's see how this works.
Almost every developer will have to write the code to handle the WebCallout -------------- or Intersoft could do it once.
Intersoft added the Group property to WebCallOut but that seems to be a waste of time if developers have to handle the other simple events that affect webCallout.
oh well.
Glenn
I'm still waiting for a fix to this critical problem. I received a hotfix for work item #585 but it didn't include this fix. It only had a fix for the the WebCallOut problem.
Has this bug been forgotten?
When testing this issue with my colleague, I was under the impression this issue is caused by the WebFlyPostBack manager. Further analysis by the developer conclude that the issue is caused by the WebCallOut and WebButton. I have logged a new bug report for the WebButton issue.
We will inform you if there is any update or progress regarding this issue.
This issue has been fixed in the latest nightly build. This fix will be included in our next hotfix which is scheduled to be released in a few weeks.
You will need to use mark the WebCallOut assigned to the buttons in the table as dirty and invoke the RefreshModifiedControl function in the [Execute] click event handler
WebCallOut1.RequiresUIRefresh = TrueWebCallOut2.RequiresUIRefresh = TrueWebFlyPostBackManager1.ClientAction.RefreshModifiedControls()
Thank you
We are planning on taking a few weeks nap while waiting for this important bug fix.
George
or
Choose this if you're already a member of Intersoft Community Forum. You can link your OpenID account to your existing Intersoft Social ID.
Choose this if you don't have an Intersoft account yet. Your authenticated OpenID will be automatically linked to your new Intersoft account.
Enter your Wordpress Blogname
Creating your account...