Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
IW10 open IW14 Form (dll)
#1
Hi,
We are preparing to migrate a large D2009/IW10 isapi application to a more recent dev environment (10.2.3/IW14.2.6 which we already have or possible go to IW15).
We would like to have the possibility to keep the current IW10 app as entry point, create a new IW14 dll that could be referenced from IW10 app and where we have migrated and new forms. So, when we have a new form migrated, we call the new IW14 version from within the IW10 app. Is something like this possible with IW? When I In VCL it is possible to include an external dll library which opens new forms, but when trying it in IW it throws AV.

How can we accomplish this? We want to keep/pass user information from IW10 app to IW14 forms.
Thanks
Alex
Reply
#2
It is not advisable to try to mix into a single binary. You could however have 2 applications that use URLs to pass control back and forth and share state via session info in a database.
Reply
#3
(06-30-2020, 05:37 PM)kudzu Wrote: It is not advisable to try to mix into a single binary. You could however have 2 applications that use URLs to pass control back and forth and share state via session info in a database.
thanks for the prompt reply. I have begun testing that scenario. In IW10 calling URL of IW14 app with coded parameter string (form to open, logged user), in IW14 in SC defined vMainForm and logged user from decoded parameter. Is this the best approach? Or how to "pass control back and forth"?

The reason I wanted to include an external IW14 dll is to have the same feel for user when entering and exiting a form (stay on same browser window). With new approach (URL to new app), browser opens new tab with IW14 form, and when "returning" (WebApplication.Terminate with its variants I get either error o stuck in an external webpage) I just want to have the new form closed and control back in calling IW10 form. Is this possible?

UPDATE: In the "RETURN" button in the IW14 form with AddToInitProc('window.close();') I can close the browser tab/window, leaving the calling IW10 again active.

Best regards,
Reply
#4
(06-30-2020, 06:13 PM)alex.trejo@tttnet.com.mx Wrote:
(06-30-2020, 05:37 PM)kudzu Wrote: It is not advisable to try to mix into a single binary. You could however have 2 applications that use URLs to pass control back and forth and share state via session info in a database.
thanks for the prompt reply. I have begun testing that scenario. In IW10 calling URL of IW14 app with coded parameter string (form to open, logged user), in IW14 in SC defined vMainForm and logged user from decoded parameter. Is this the best approach? Or how to "pass control back and forth"?

The reason I wanted to include an external IW14 dll is to have the same feel for user when entering and exiting a form (stay on same browser window). With new approach (URL to new app), browser opens new tab with IW14 form, and when "returning" (WebApplication.Terminate with its variants I get either error o stuck in an external webpage) I just want to have the new form closed and control back in calling IW10 form. Is this possible?

UPDATE: In the "RETURN" button in the IW14 form with  AddToInitProc('window.close();') I can close the browser tab/window, leaving the calling IW10 again active.

Best regards,
Could you please elaborate on the "pass control back and forth and sharing of state via session info"?

What I accomplished thus far is pass control from IW10 entry app via NewWindow(URLofIW14app_withParams). And when in the IW14 form the user hits "Return" I close the tab. I don't know how to keep the SessionTimeOut from expiring in IW10 entry app if user is working on IW14 app longer, and how to pass control back other than closing the IW14 app & browser window.

Thanks
Reply
#5
You can use some kind of token or to pass back and forth either by cookie or URL. You can even use one of the session IDs and then just store your info for that user in a database and access it from both applications.

For session, just increase the time outs. If you really need to coordinate you can set a flag in the DB for that user an with in each application refresh the sessions that are alive in the other instance of the application.
Reply
#6
(07-01-2020, 05:28 PM)kudzu Wrote: You can use some kind of token or to pass back and forth either by cookie or URL. You can even use one of the session IDs and then just store your info for that user in a database and access it from both applications.

For session, just increase the time outs. If you really need to coordinate you can set a flag in the DB for that user an with in each application refresh the sessions that are alive in the other instance of the application.

Thank you very much, this is unchartered territory for me. It is clear how a calling app can pass via URL parameters to a called app, what I don't have clear is how a called app can pass back info (URL or otherwise) to the calling app, such as an "I'm back" signal.

In the sessionID scenario, where user info from calling app is stored in database, I would use sessionID as parameter in URL and called app would access the info and process accordingly, right?

When exiting calling app, just window.close is enough or a WebApplication.Terminate is needed?
Reply
#7
(06-30-2020, 12:11 AM)alex.trejo@tttnet.com.mx Wrote: Hi,
We are preparing to migrate a large D2009/IW10 isapi application to a more recent dev environment (10.2.3/IW14.2.6 which we already have or possible go to IW15).
We would like to have the possibility to keep the current IW10 app as entry point, create a new IW14 dll that could be referenced from IW10 app and where we have migrated and new forms. So, when we have a new form migrated, we call the new IW14 version from within the IW10 app. Is something like this possible with IW? When I In VCL it is possible to include an external dll library which opens new forms, but when trying it in IW it throws AV.

How can we accomplish this? We want to keep/pass user information from IW10 app to IW14 forms.
Thanks
Alex

The problem is how to share the session state (internal session data, like "what's the logged user?). It is feasible if you program your application like it was a REST server (i.e. each request does one unique thing an that's it, no complex stuff depending on transactions, etc.)
Otherwise I recommend you to migrate it completely.
Reply
#8
It doesnt have to be full REST as each page can maintain state while its alive. Its only state that is needed between different pages that needs to be stored, essentially shared info of the user session.

I think mixing them though is going to be complex and I agree with Alexandre, Id port it all or at least separate it into groups of pages as modules and then just interop between modules rather than try to do it with full page granularity.
Reply
#9
(07-02-2020, 06:52 AM)Alexandre Machado Wrote:
(06-30-2020, 12:11 AM)alex.trejo@tttnet.com.mx Wrote: Hi,
We are preparing to migrate a large D2009/IW10 isapi application to a more recent dev environment (10.2.3/IW14.2.6 which we already have or possible go to IW15).
We would like to have the possibility to keep the current IW10 app as entry point, create a new IW14 dll that could be referenced from IW10 app and where we have migrated and new forms. So, when we have a new form migrated, we call the new IW14 version from within the IW10 app. Is something like this possible with IW? When I In VCL it is possible to include an external dll library which opens new forms, but when trying it in IW it throws AV.

How can we accomplish this? We want to keep/pass user information from IW10 app to IW14 forms.
Thanks
Alex

The problem is how to share the session state (internal session data, like "what's the logged user?). It is feasible if you program your application like it was a REST server (i.e. each request does one unique thing an that's it, no complex stuff depending on transactions, etc.)
Otherwise I recommend you to migrate it completely.
Alexandre,
I totally agree that a full migration is the best approach. We are actually working on it as a parallel project. However, due to the size of the IW10 application and the urgency to add some functionality/forms that require Async capabilities not available in IW10, we need to consider this mixed environment. Being able to add a dll library in IW14 with new forms/funtionality to the IW10 app would have provided a very usefull middle ground (forms/funcionality in that dll library would serve to both actual IW10 app and migrated IW14 project), not having to control info passing to and from 2 apps. The app is not a REST server, that is why I don't see how to provide with the "back" communication, other than the calling app constantly polling database, which is undesirable. Thanks for your comments, I appreciate very much the support of such giants as yourself and Kudzu.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)