Hi Bon, 

What do you mean by “The new WebUI dialogs do NOT wait for the user to respond before running next snippets” ? 

For WebUI dialogs, you will have Yes, No and Cancel as the actions and the remaining code in the actions procedure. If you don’t respond to the dialog message, then the action statements will not be executed. Do you experience the opposite ? If yes, can you share which version ? 

you are not allowed to run the Logoff Procedure to close the application from outside the traditional “X” to close.

Yes, closing the tab will terminate the data session after a preset timeout which is 5 minutes now. At this point of time, the only way to terminate a session is to include a button linked a procedure with code pro::sessionmanager::FinishSession();

Here’s a simple example:

The two above happen in succession, patiently waiting on the user to respond before moving on to the next lines of code.

Now look at the same code in WebUI. This is NOT refactoring the code, but merely replacing WinUI code with WebUI code:

WebUI attempts to handle the second popup without waiting for the first to get a response.

The solution, of course, is this:

But, that simple code required TWO procedures, not one. The problem compounds when you have multiple popups. 

************************************************************************

Now let’s consider the closing of the application. 

We want to ask the user in WebUI if they want to save changed data. So I change the logoff procedure in settings and create the following code:

But of course this doesn’t work, because I need to return something via PR_ConfirmCloseApplication in order to actually close the application. 

I’ve tried using ExitAimms, using the close procedure recursively and others, but cannot figure out how to do this.

Does that help explain what I am talking about? 

@MathFour , thanks for the detailed explanation.

As you write, you already know the solution to your dialog messages. You will need to put the second dialog message in the actions of the first one, so you will need multiple procedures for such a workflow.

Please realize that WinUI and WebUI are completely different technologies and there will be things that need to done differently. Sometimes easier, sometimes more cumbersome.

A WinUI app considers clicking on the close X button as a quit the app action. In WebUI, closing the tab does not quit the app. You can CTRL+SHIFT+W to reopen the tab and have your app session still available. The session will automatically terminate after a certain time of inactivity, default time is 5 minutes. You can include the function pro::sessionmanager::finishsession() in your workflow, which will close the current session immediately.

In our collaborative webUI project, if the user is not within his collaboration time window, and if he opens the app, we pop up a dialog message describing it and after he presses “OK”, we finish the session, as@mohansx stated.

ci::Proc_FinalizarSessaoWebUI Code:

@mohansx  after we finish the session, the browser automatically downloads a log. Is there any way to avoid that?

Another question: If we put this requestPerformDialog inside a webUI pageOpenProcedure it returns an error saying that other procedure is already queued. Is there any workaround for it?

Thanks!

@mateusarakawa 

after we finish the session, the browser automatically downloads a log. Is there any way to avoid that?

Unfortunately, at this point of time - no. However, this might change and I will update you if this behavior will be changed in a future version. 

Another question: If we put this requestPerformDialog inside a webUI pageOpenProcedure it returns an error saying that other procedure is already queued. Is that any workaround for it?

That is strange, what version of AIMMS are you using ? I have the below requestDialog procedure as the procedure upon load for the home page in one of my applications. It works as expected, as soon as WebUI is launched, a dialog is opened. My project is in 4.69.5.9

Procedure prHomeDialog {
    Body: {
        if bpShowDialog then
        
        webui::RequestPerformWebUIDialog(
            title   : "Do you want to load a previously saved data case?" , 
            message : "Select Yes to load one of them, No to upload a new input file",
            actions : sActions , 
            onDone  : 'prHomeDialogActions' );
        endif;
    }
}

@mohansx , Thanks! I think I might found the reason this error is popping up. There is a warning dialog box saying that we are using deprecated page action functions (we still need to change for the string parameter approach). So, when we request another dialog page, this error pops up: 

I’m still wondering why this error happens within the server, because the warning regarding deprecated page actions does not pop up in user mode. I tried the fastest way to workaround this: empty the webui::Requests set, but unfortunately it is not available in the library interface.

Thus, I think we need to change our page action functions approach in order to solve this. I’ll update this thread. For this instance, I used aimms 4.69.6.

@mateusarakawa maybe you already know, but here is something about upgrading the page actions https://how-to.aimms.com/Articles/295/295-convert-page-actions.html

Thanks y’all. This discussion has helped.

However, I’m still unable to prompt the user to save (or not save) changed data in WebUI and then exit from there. Is there a way to do this WITHOUT using PRO? 

My user will be on PRO, but during development, it’d be nice if I could have this action happening and looking mighty close to the way it’ll look during production. 

Thanks!

Bon

We are looking at a way to see if we can add a CloseApplicaton() function into the WebUI library that you can use to gracefully exit and be in control what happens in addition to that (e.g. first a DialogMessage with an “Are you sure?” or a data save.

This function will also resolve (in fact, that was the main reason we are considering it) to release the license seat of the user being released (assuming it’s the only app being active of that user) and not having to wait till the ‘expiration’ time is over (the latter is there to not have to restart each time if you temporarily close your App ).

Current thinking, and btw this is NOT a User Logoff but an Close Application function as we don’t expect users to want to necessarily close all Apps but only that specific App, is that the procedure has 1 argument being a URL. This is where the browser will go while closing the App. If no URL is provided, the active App Store will be opened.

webui::CloseThisApplication(MyURL)
 input: MyURL ! Optional; if empty, opens current AIMMS App Storefront

Please know this is in idea stage and not planned yet. However, felt it would be good to let you know so you can provide feedback.

Thanks for helping making AIMMS better!

Thanks for the info, Gertjan.

In the meantime, I’ve posted my app on a test PRO server we have and I can’t make my app close properly. 

When I include only 

pro::sessionmanager::finishsession();

in my procedure to close, I also get the connection-lost.log file. And I don’t have any page actions (I even searched ALL my files for “action.” to make sure). 

I wouldn’t mind the renegade file, but the browser window doesn’t close. It stays perpetually in “busy” mode.

I’d like to be able to call the FinishSession() inside of a dialog callback procedure, but if I can’t even make it work all by itself, I’m at a loss.

Please help.

When I include only 

pro::sessionmanager::finishsession();

in my procedure to close, I also get the connection-lost.log file. And I don’t have any page actions (I even searched ALL my files for “action.” to make sure).

I wouldn’t mind the renegade file, but the browser window doesn’t close. It stays perpetually in “busy” mode.

That is the current behavior of pro::Sessionmanager::finishsession(). When you make a call to this function, your app goes to all pre-termination and termination procedures. However, the browser thinks that this is an unexpected lost connection and triggers the log file download. 

The browser tab stays in the perpetual state but if the download prompt is raised, then your app has been terminated. You have to manually close the tab.

These two behaviors are what Gertjan mentioned in his comment that we have plans to change. Do not trigger a log file download and take the tab to a different url instead of the perpetual busy state.