01-30-2020, 09:43 PM
(This post was last modified: 01-31-2020, 12:06 AM by Alexandre Machado.)
> It's an old bug which I also remember (sync and async were mutually exclusive on a form), maybe a pre 14 issue.
This is not a bug. If you can explain what the issue is I can also make the explanation clearer.
Sync and Async are mutually exclusive on a per-component/event basis. You can't have a button with both OnClick (sync) and OnAsyncClick (async) events at the same time. Only one of them will fire (the pattern in IW code is to render the sync event and discard the async event, but this can vary from control to control, especially in 3rd party code).
This is not a bug. There is no sane way to make both work because you can't just post an async request to the server and, at the same time, post a full HTTP request which reloads the page (discarding all previous state of the previous page, including the "code" that expects an async response).
This is the very basic nature of how the web, HTTP and XMLHttpRequest work.
It doesn't mean that you can't have both sync and async for different controls and/or different events. You can certainly have a IWButton using sync events an another IWButton using async events on the same form. And you can certainly have the same component having sync and async events assigned at the same time (just not the same DOM event), i.e. you can possibly have OnChange [sync] and OnAsyncKeyDown [async] assigned to the same control. Sometimes it doesn't make sense to mix them but there is no technical limitation.
If you can recreate, in a simple test case using only IW native controls, one case where switching (creating/showing/releasing) a IWForm doesn't work as expected I will investigate. But currently there are no known issues like that. To be honest, you are the first one to describe such problem in a long time.
As I mentioned, CG controls do lots of stuff outside the scope of IW, including but not limited to changing the DOM directly via JavaScript. If some CG control messes with the DOM when a page is loaded (via sync or async call), there is very little I can do except changing/fixing any behavior from IW side that can be affecting CG controls, if that's the case.
According to our logs, all bugs or issues reported to us by CG Dev Tools team have been fixed *last year*, before Christmas. I spent a good part of December hunting and fixing things in our code that were impacting CG controls and there are no open issues. So, from my knowledge, CG should be able to create a perfectly working version of their tools compatible with IW 15.1.12 (our latest version). Bob9999, who created this thread, is certainly having issues that we have already fixed because he is stuck in 15.1.7. Seems that it is not your case, but I just want to make it clear too.
> I'm not understanding the value of removing relevant info from a post when it could help someone else, maybe anyone stuck on an early 15 release. Removing the info makes the issue less clear, not more clear.
I'm not exactly sure what's the relevant info that has been removed. Can you please elaborate?
This is not a bug. If you can explain what the issue is I can also make the explanation clearer.
Sync and Async are mutually exclusive on a per-component/event basis. You can't have a button with both OnClick (sync) and OnAsyncClick (async) events at the same time. Only one of them will fire (the pattern in IW code is to render the sync event and discard the async event, but this can vary from control to control, especially in 3rd party code).
This is not a bug. There is no sane way to make both work because you can't just post an async request to the server and, at the same time, post a full HTTP request which reloads the page (discarding all previous state of the previous page, including the "code" that expects an async response).
This is the very basic nature of how the web, HTTP and XMLHttpRequest work.
It doesn't mean that you can't have both sync and async for different controls and/or different events. You can certainly have a IWButton using sync events an another IWButton using async events on the same form. And you can certainly have the same component having sync and async events assigned at the same time (just not the same DOM event), i.e. you can possibly have OnChange [sync] and OnAsyncKeyDown [async] assigned to the same control. Sometimes it doesn't make sense to mix them but there is no technical limitation.
If you can recreate, in a simple test case using only IW native controls, one case where switching (creating/showing/releasing) a IWForm doesn't work as expected I will investigate. But currently there are no known issues like that. To be honest, you are the first one to describe such problem in a long time.
As I mentioned, CG controls do lots of stuff outside the scope of IW, including but not limited to changing the DOM directly via JavaScript. If some CG control messes with the DOM when a page is loaded (via sync or async call), there is very little I can do except changing/fixing any behavior from IW side that can be affecting CG controls, if that's the case.
According to our logs, all bugs or issues reported to us by CG Dev Tools team have been fixed *last year*, before Christmas. I spent a good part of December hunting and fixing things in our code that were impacting CG controls and there are no open issues. So, from my knowledge, CG should be able to create a perfectly working version of their tools compatible with IW 15.1.12 (our latest version). Bob9999, who created this thread, is certainly having issues that we have already fixed because he is stuck in 15.1.7. Seems that it is not your case, but I just want to make it clear too.
> I'm not understanding the value of removing relevant info from a post when it could help someone else, maybe anyone stuck on an early 15 release. Removing the info makes the issue less clear, not more clear.
I'm not exactly sure what's the relevant info that has been removed. Can you please elaborate?