First off, the last registered version of TMS Intraweb controls I have is 5.0.0.0 but I have an expired registration.
I'm having trouble with an async message dialog with a content region being interfered with by an async timer.
For example, when the timer goes off, any listbox position is reset to the top of the list and any field focus, in an edit field for example, is lost. I use the async timer to update some other fields on the background form and also on the dialog region.
Is there anything that can be done about this in the version I have? Does the latest version of the controls resolve this problem?
To replicate simply put a advmessagedialog with a content region on a form along with a IWTimer. Once the dialog is open select another item in the listbox or select an edit field in the dialog... when the timer does it's async callback the focus in the edit field and the list position will be lost.
- I have not been able to reproduce the issue with the listbox position that gets reset. Can you please provide a ready to run sample project that demonstrates the issue so I can further investigate this?
Can you also let me know which version of IntraWeb and which browser you are using?
You simply have to scroll the listbox and select an item. When the async event occurs:
CHROME: the list box will reset to the top of the list (the item remains selected just out of view).
IE: the list box will scroll the selected item to the top of the list.
Obviously the desired behavior would be to not affect any of the elements in the dialog at all when an async event occurs. I'm using it as a record detail editor so I don't have to open a new page to edit the detail.
I just need confirmation that when using it in this way an an async timer occurs that the contents of the dialog remain unchanged and I will order the latest version.
just to be clear... what I mean of course is that I cannot test AsyncUpdateRequired to determine if async event timers can work with the messagedialog since that was added after 5.0.0.0. If it does work correctly with that set then I'll be glad to buy the latest version but if not I don't have time and will have to use alternate mechanisms. thanks.
Follow up: the AsyncUpdateRequired := false seems to work well. Thank you.
HOWEVER, other issues still exist. I'm not sure if this is directly related to TMS code or the base Intraweb code but I thought I'd ask here first to see. Since this only can be shown with IWAdvMessageDialog I assume it's something in TMS code.
Scenario:
I have a dialog with a content region. The content region is a 'form' with edit fields, etc. on it. I want to pre-populate those fields with (for example) the detail of a grid row... allow some editing... and then save. Alternately, I would like to Asynchronously set values of some of the edits (perhaps with a timer or notifier).
In Chrome and FF if I set the TEXT property of an IWEdit on the content region it correctly sets the value and displays it when I call Dialog.ShowAsync. Any async events that update the fields on the ContentRegion work correctly and update the fields immediately (great!!).
In IE 9 (and other IE versions) it does not work at all. I've tried HTML5 and Quirks mode.
I've emailed two sample programs exhibiting these issues.
I set the text value of an IWEdit before calling Dialog.ShowAsync, The fields do not show that value when the dialog appears. In fact if I subsequently (through an AsyncTimer or other AJAX mechanism) attempt to set the text property of an IWEdit (or ListBox, etc.) that are on the ContentRegion they do not appear. Works great in Chrome.
IW 12.2.12.1 (and also tested with test release IW 12.2.13)
Unfortunately this issue is related to the way IntraWeb interacts with the DOM changes of the page in IE. These changes are required to display the content region inside the IWAdvMessageDialog. As we have no control over the interaction between IntraWeb and IE we currently have no solution available for this issue. It does however work as expected in other browsers and we'll investigate if the behavior can be improved for IE in a future version.
As a workaround I would suggest using a synchronous update instead of an asynchronous update in this case.
One more suggestion... when a modal dialog is active, scrollbars appear on the browser... I imagine something to do with the 'shading' effect of a modal... as my pages are configured to auto-resize to fit the current browser window this is kind of inconsistent. Is there some way to have the dialog display without having it create the browser scrollbars? An explanation of exactly what it causing this would help. Thanks.
This is caused by the overlay that is rendered behind the IWAdvMessageDialog. The overlay is used to create the "shading" effect and to make sure that the IWAdvMessageDialog is displayed as a modal dialog.
It's the same effect that is noticeable from time to time when a default IW control is client aligned on the form so this could be a IW related issue. However, I'll investigate if this behavior can be improved in a future version.