Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Weird session form overlay issue and memory leaks
#1
Hi there.  I have a really weird thing occurring in my project (IW15.1.7) that I wanted to post here to see if there is something wrong in the way the session state is kept or something I need to use a different approach or command for.

The form that I have been able to replicate the issue with is an AsyncClick event off of a IWImageButton.  The form blinks and is like the form is reloaded.  Then when I click on the button again, the new form is loaded (that is all this button is doing is just loading a new form) but the old form stays on the screen and the new one displays as well.  All components are active and needless to say this is all rather confusing.  Then I click on the refresh button and then the new form reloads without the old form there.  

The other situation that is occurring that I cannot recreate (user just keeps running into this and complaining) is that I am on an existing customer form and all seems OK.  Then I click on a button the same way (except this button is just a IWButton) and the new form loads 100%.  Then when I click on the new customer button, this original form loads but will keep fields filled in rather than being blank from the beginning form that was loaded that started this situation.  I tried to initialize the fields programatically just in case and in design the fields are all blank of course.  I have traced all logic paths and cannot seem to find the issue so I am thinking something is occurring in the session layer like the situation above.

Situation 1 is like the async event is uninterrupted and the same form is just stuck.  Then when click the button again it then overlays over the previous form instead of loading sovereign

Situation 2 seems to be that the form is not loading sovereign and has an image from the last time it was loaded.  I am going to review the data feed just in case but why would the fields still be displaying data when they are loaded fresh like this?  

The way I load new forms is:

TfAdminSettingsGeneral.Create(WebApplication).Show;
Release;
 
So the old form should be released from session and memory but somehow there is a shadow kept from before.  By the way, I have not posted this issue yet but there seems to be some sort of memory leak over time and I suspect this release command is not 100% releasing forms from memory.  Over time my service gets too high in RAM usage and I have to restart the service.

Cheers.
Reply
#2
"but the old form stays on the screen and the new one displays as well"

To be honest, nothing even remotely similar to that has never been reported, ever.

This is something that just can't happen. The stream that creates the HTML output of a form comes from a single source. There is no way that 2 streams get somehow "merged" in some weird way and both become somehow "visible". There is no way for 2 forms to render the HTML output in response to the same request. Even if it were possible, the browser will always replace the current HTML with the new one.

So, it would be nice if you can provide more information.

Once you seem to be stuck in 15.1.7 I suspect that you also have CG Dev on it? Maybe CG Dev is doing that iand not IW?
Reply
#3
Hi Alexandre.  

That is the odd thing is the web application is at the correct page and when I click browser refresh button then that kicks the browser to load a fresh version.  Then all is OK again.  If you give me an email address, I can send you a link and login credentials so you can see this effect.  One I can reproduce like clock work.

In design everything is sitting on a CG region.  I then have a mix of IW and CG components as needed for the solution.  

One issue is with fields on top of a CG region and another situation is inside a CG accordion on top of a CG region.  The situation that I will email you if intersected will have step by step so you can see what I mean.

Even if CG is doing something weird I cannot see why a new form loading can be non-sovereign.  The browser should show a new form absolute and this is where I get stuck.  I can see if the form is being changed async and staying loaded but I am going to a whole new form.

Cheers.
Reply
#4
I also had some weirdness when loading new forms via async clicks.  Since async doesn't really apply when loading a new form (should only help when updating controls on an existing form) I changed the async onClick's to normal onClick's and all form launching worked from then on.  Tried but couldn't reproduce on 15.1.12 but also have removed all third party controls too.  Maybe launching forms with normal onClick's would be a temporary work around.

Regards,
Mark
Reply
#5
> A previous release would not allow both types of clicks (non-async would not function with async clicks on form) but I see now that this is fixed so looks viable.  

I have no idea if you are talking about IW or CG code here... IW has always worked in both sync and async modes.
Reply
#6
(01-23-2020, 07:35 PM)bob9999 Wrote: Hi Alexandre.  

That is the odd thing is the web application is at the correct page and when I click browser refresh button then that kicks the browser to load a fresh version.  Then all is OK again.  If you give me an email address, I can send you a link and login credentials so you can see this effect.  One I can reproduce like clock work.

In design everything is sitting on a CG region.  I then have a mix of IW and CG components as needed for the solution.  

One issue is with fields on top of a CG region and another situation is inside a CG accordion on top of a CG region.  The situation that I will email you if intersected will have step by step so you can see what I mean.

Even if CG is doing something weird I cannot see why a new form loading can be non-sovereign.  The browser should show a new form absolute and this is where I get stuck.  I can see if the form is being changed async and staying loaded but I am going to a whole new form.

Cheers.

My e-mail is alexandre [at] atozed dot com

Async events can be used to load forms just like regular events do. The whole form is generated and the old form is *fully* replaced with the new one. 

What you describe doesn't look like consequence of IW code, but CG code. I'm not responsible for CG and I honestly have no idea what their components are doing under the hood (including direct DOM manipulation which can have absolutely *any* consequence and/or side effect).

If have an online application showing this behavior, I'd like to see it, but I can't guarantee that there is anything I can do about it (if it is caused by other 3rd party code).

Cheers
Reply
#7
(01-23-2020, 08:02 PM)MJS@mjs.us Wrote: I also had some weirdness when loading new forms via async clicks.  Since async doesn't really apply when loading a new form (should only help when updating controls on an existing form) I changed the async onClick's to normal onClick's and all form launching worked from then on.  Tried but couldn't reproduce on 15.1.12 but also have removed all third party controls too.  Maybe launching forms with normal onClick's would be a temporary work around.

Regards,
Mark

As mentioned in my previous answer, a form *can* be created and shown during an async event. There is no restrictions to that.
Reply
#8
>>I have no idea if you are talking about IW or CG code here...
>>IW has always worked in both sync and async modes.

It's an old bug which I also remember (sync and async were mutually exclusive on a form), maybe a pre 14 issue. 

>>As mentioned in my previous answer, a form *can* be created and
>>shown during an async event. There is no restrictions to that.

I was trying to say that by noting I couldn't reproduce my old async -> form creation issue on 15.1.12 and that switching to sync mode would be a temporary work around.

I noticed you edited bob9999's post where he acknowledged my suggestion worked and also wondered if it would fix the memory leak. 
I found this item in the 15.0.4 Version History:
Bug fixes
Calling IWForm.Release() from async method could fail
https://www.atozed.com/2018/06/15-0-4-h/

Seems like this could explain everything and maybe it wasn't really fixed until a later release.  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.  It also uncaptured the effort taken to test and acknowlegde a fix for a serious production issue.

As a long time customer 

[Image: MJS_ATOZED.png]

let me say that I believe IntraWeb is a brilliant piece of work and I appreciate your expertise and efforts.  That said, on almost every IW project I've implemented there's always something.  Some little thing (or occasionally a big thing) that will cost me hours of investigation and workarounds which makes it tough to estimate and deliver on time.  As much as I admire IntraWeb it has given me a few gray hairs over the years.  My theory is stuff falls through the cracks because you don't use a dedicated defect tracking system with priorities, time estimates, etc.  And product documentation - IW would be more organized, maintainable, and understandable if the documentation were kept up to date and defects were formally tracked.  

Regards,
Mark
Reply
#9
> 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?
Reply
#10
Hi there.  I was finally able to upgrade to 15.1.12 and am still testing but I have enough information now to add more here on this thread.  Good to know there was a previous bug where the release could fail in an async event.  With me changing over to non-async now for form loads where I can, I will see how this goes for memory leaks and let you know my results.  I am still regression testing everything in my application in this moment before I will get to the retest on memory and let you know my results.

The Webapplication.FormWidth seems to still be an issue.  I am using in the form render event where I found the most accurate in the previous version I was on.  The button I am placing to the right of the form floating still has a mind of its own although this is way less crazy than before.  Interesting enough the change from left to right anchor on the button seems to be working now where I had to use this manual placement so perhaps I can abandon this method now.  There was of course a new CG release so it is possible this is a factor.  I am going to experiment more with this application variable and let you know if I got this to work.  

Thank you all for your comments to date.  This is very helpful for more insight and to widen the IW knowledge base for others.  I wanted to also concur that it would be nice if the IW documentation would change from "work in progress" to a general first release.  Sometimes it is not easy to find out how to use some component properties and the demo cannot have everything and allot of time has to be invested at times to figure things out.

Cheers!
Reply


Forum Jump:


Users browsing this thread: 3 Guest(s)