application timeout

[csda1]

Re: application timeout

Hi Dave,

Does a5_close truly close all tables, even those "orphans"?

Yes it does, but A5 crashes are another thing. Once the stack is toasted, anything can happen.

[Ed Barley]

Re: application timeout

Thanks Ira


Ed

[davidv43]

Re: application timeout

Then perhaps a wish list function would be an "untoaster".

Dave

[CALocklin]

Re: application timeout

Interesting - Ira and I have been communicating off line and he showed me that a ui_modeless_dlg_close() command will close a modal dialog if run from the %Code% section of a modeless xdialog based on a {timer} event -- that's something I had never tried.

However, I cannot make a ui_modeless_dlg_close() command close a modal xdialog from a script activated by a script_schedule() command -- that's something Ira had never tried.

So, I guess we were both 1/2 right - or completely right about our particular method. Take your pick.

At any rate, it may be helpful for others to note these differences. You could build a {hidden} modeless xdialog that will close other modal xdialogs.

The problem I see with that is knowing what xdialog titles are open (and I haven't found any 'ui_dlg_list()' function) so ui_modeless_dlg_close(dialogtitle) isn't very useful for forcing a remote app to close unless you either create and maintain a list of all possible dialog titles or create and maintain a global variable to either store the name of all xdialog(s) that are currently open or store all xdialog titles that have been opened since the app started. (I didn't ask, maybe Ira has a way to do this.) (Most would understand that multiple modeless xdialogs could be open at the same time. For those who aren't sure, yes, it is also very possible to have multiple modal xdialogs open at one time. Just open a new one from within an existing modal xdialog by calling a function that opens the second modal xdialog. This is something I do quite often - one modal "parameter input" xdialog is open and the user can open another modal "instructions" xdialog from within it.)

I haven't tried the idea of using a variable with the xdialog title(s) and running a routine to close it/them when shutting down the app. Consequently, I don't know what issues you would run into. Do the xdialogs have to be closed before the forms? Do they need to be closed in reverse sequence? Is a time delay required to make sure each xdialog has closed down before the next one is closed? Other?? Hopefully none of those would be an issue but I'm sure that attempting to close an xdialog that is NOT open would generate an error so that would have to be trapped and handled.

My conclusion - I don't think there is any really easy way to close xdialogs in order to close down a remote workstation. It can be done but it will take some work no matter what method you use.

EDIT: I suppose you could open a hidden modeless xdialog before every modal xdialog and have a timer event in the modeless xdialog that tests for some "shutdown variable" then (a) the modeless xdialog could shut them both down if a shutdown was commanded and (b) the 'close' action for the modal xdialog could also close the modeless xdialog. But, if you even followed that, it does seem like it would get a bit cumbersome. (However, trying to process that whole concept gave me another idea I'll have to test.)

[csda1]

Re: application timeout

Hi Cal,

The problem I see with that is knowing what xdialog titles are open (and I haven't found any 'ui_dlg_list()' function) so ui_modeless_dlg_close(dialogtitle) isn't very useful for forcing a remote app to close unless you either create and maintain a list of all possible dialog titles or create and maintain a global variable to either store the name of all xdialog(s) that are currently open or store all xdialog titles that have been opened since the app started. (Most would understand that multiple modeless xdialogs could be open at the same time. For those who aren't sure, yes, it is also very possible to have multiple modal xdialogs open at one time. Just open a new one from within an existing modal xdialog by calling a function that opens the second modal xdialog. This is something I do quite often - one modal "parameter input" xdialog is open and the user can open another modal "instructions" xdialog from within it.)

It is possible with version 8 and up to get a list of XDialog's that are open (modal or modeless), and in fact you can see this in the Modal Windows Watch List (which actually shows both Modeless and Modal) of the CSDA Screen Capture program. (BTW - a bug has cropped into in version 0.90 install routine that I am debugging - hopefully it will be solved in a day or two for version 0.91)

I haven't tried the idea of using a variable with the xdialog title(s) and running a routine to close it/them when shutting down the app. Consequently, I don't know what issues you would run into.

None

Do the xdialogs have to be closed before the forms?

No

Do they need to be closed in reverse sequence?

No

Is a time delay required to make sure each xdialog has closed down before the next one is closed?

No

Other??

None

Hopefully none of those would be an issue but I'm sure that attempting to close an xdialog that is NOT open would generate an error so that would have to be trapped and handled.

Use UI_MODELESS_DLG_EXIST(dialogtitle) to test before close or use error trapping (which is better, just in case two threads are trying to close the same box)

My conclusion - I don't think there is any really easy way to close xdialogs in order to close down a remote workstation. It can be done but it will take some work no matter what method you use.

Don't worry about it. If you close Alpha Five, all the dialogs and XDialogs will go away. Depending upon flags, you may be prompted for saving dirty screens (e.g. code editor code), but I prefer to shut things down in as clean a way as possible, so I always include an option to close my dialogs with a cleanup exit, to make sure everything is dotted and crossed.

EDIT: I suppose you could open a hidden modeless xdialog before every modal xdialog and have a timer event in the modeless xdialog that tests for some "shutdown variable" then (a) the modeless xdialog could shut them both down if a shutdown was commanded and (b) the 'close' action for the modal xdialog could also close the modeless xdialog. But, if you even followed that, it does seem like it would get a bit cumbersome. (However, trying to process that whole concept give me another idea I'll have to test.)

Of course, each XDialog could also just close itself upon detecting the closedown variable within the timer event, but it's not really necessary.

[G Gabriel]

Re: application timeout

Interesting - Ira and I have been communicating off line and he showed me that a ui_modeless_dlg_close() command will close a modal dialog if run from the %Code% section of a modeless xdialog based on a {timer} event -- that's something I had never tried.

However, I cannot make a ui_modeless_dlg_close() command close a modal xdialog from a script activated by a script_schedule() command -- that's something Ira had never tried.

I don't understand why Ira keeps on perpetuating myths and refuses to admit when he is wrong. He raised this issue in another thread and I showed by way of example that ui_modeless_dlg_close() does NOT close a modal xdlg. Now, and with my response regarding {timer} in this thread, evidently a light went off in his head and found an opportune chance to try to prove that he was right so he piggy backs ui_modeless_dlg_close() on {timer} to prove his point. That does not prove the point. With {timer} in modal xdlg you could kill a Camel with a sling shot. As in this thread, I have shown that with {timer} you could do what you couldn't do otherwise: close the modal xdlg. It has nothing to do with the original point that ui_modeless_dlg_close() would close a modal xdlg. In and by itself, it does not. I find it rather unethical to say the least to mislead people who don't know any better. I surely try to avoid these confrontations, but to plant wrong ideas in peoples' heads particularly when they think that you know it all, is wrong. Ira seems to make a lousy habit of this. This is not meant to disparage Ira, only to tell everyone not to take anything for granted regardless of who says it.
I try very hard to disregard these confabulations, but also feel fiduciary duty to those who use the message board as a great source of learning.
Buyer beware.

[csda1]

Re: application timeout

I don't even know how to respond to the previous post except

ROTFL

Everything I said is correct, but go off in your little world believing whatever you want!

For everyone else, here is some code to try and to modify that will illustrate it for yourself.

First, create the following code as a UDF

'Date Created: 05-Feb-2010 07:52:18 PM
'Last Updated: 05-Feb-2010 07:52:18 PM
'Created By  : Ira J. Perlow
'Updated By  : Ira J. Perlow
FUNCTION XdialogTimerTest AS C (Close_Dialog as C,Close_Time=(NOW()+20) as T)
'DESCRIPTION:  Runs XDialog Code with Timer events for testing

'=========================================================================
' Created by Computer Systems Design & Associates
' Copyright 2010 Computer Systems Design & Associates, All Rights Reserved
' http://www.csda1.com

' You may use this code at your own risk in whole or as a part for personal
' use only
'
' No other use is granted without written permission from the author
' including any commerical code library or instructional guide
'=========================================================================
' Run the next two lines (without the single quote comment character
' in the Interactive editor or any other code
'        XdialogTimerTest("TestModal",NOW()+20)
' This next line can't be run until "TestModal_2" Xdialog closes
'        ui_dlg_box("TestModal","This is a sample modal Xdialog box;<ok>")
' 20 seconds after starting XdialogTimerTest() above, 
' the "TestModal" Xdialog will close if it exists
'=========================================================================
' Function Input Parameters
'    Close_Dialog - Name of Xdialog box, modal or modeless, to Close
'    Close_Time - Time to wait until to execute code
'                defaults to current time + 5 seconds
' Function Output - null string
'=========================================================================
' Set return value to null
XdialogTimerTest=""

dim Close_Dialog as C
dim Close_Time as T
'close_dialog="TestModal"
'close_time=NOW()+5


dim close_time_TestModal_2 as T
close_time_TestModal_2=NOW()+10

dim dlgtit as c
dlgtit="XDialog Timer Test"

dim dlgbdy as C 
dlgbdy=<<%dlg%
{position=remember=sticky}
{size=remember=sticky}
{startup=init}
{can_exit=close}
{timer=timerevent}
{interval=1}
Current Time:[timevalue] <*15Test Code!TestButton>;
{stretch=height,width}
[%m%.43,5display];
%dlg%

dim dlgevt as c
dlgevt=<<%code%
' Get upper trimmed event name for tests
dim buttxtu as c
buttxtu=UPPER(alltrim(a_dlg_button))

' clear event variable
a_dlg_button=""

if (buttxtu=="CANCEL").or.(buttxtu=="CLOSE")
    ' If closed with the "Red" X in upper right corner
    ' or if Cancel button is pressed (if we have one)
    ' then close this XDialog
    ' The exist test below, while not really needed here,
    ' is generally a good safety net.
    IF ui_modeless_dlg_exist(dlgtit)
        ui_modeless_dlg_close(dlgtit)
    END IF
else if (buttxtu=="TIMEREVENT")
    ' Set the new time value to display so we 
    ' can see ticking seconds of the timer event
    timevalue=time()
    ' Display time value on status bar as well
    statusbar.set_text(timevalue)

    ' Display some text so we can see something
    ' Get list of open MDI type A5 windows
    display=a5_list_open_windows()

    ' After 10 seconds we will close the "TestModal_2" 
    ' modal Xdialog box we opened after we started 
    ' this Modeless One
    IF now()>close_time_TestModal_2
        IF ui_modeless_dlg_exist("TestModal_2")
            ui_modeless_dlg_close("TestModal_2")
        END IF
    END IF

    ' We'll wait for close_time until we do something
    IF now()>close_time
        ' time has passed, now we'll do what we want to do
        ' You can put any code you want here, and Alpha will
        ' execute it if this event is occuring (which is 
        ' indicated by the changing time value on the display)

        ' See if Xdialog (modal or modeless name) we specified
        ' on the function's parameters exists
        ' and close if it does
        IF ui_modeless_dlg_exist(close_dialog)
            ui_modeless_dlg_close(close_dialog)
        END IF
    END IF
else if (buttxtu=="INIT")
    ' Initialize a time value to display so we 
    ' can see ticking seconds of the timer event
    dim timevalue as c
    timevalue=time()

    ' Display some text so we can see something
    dim display as c
    display=a5_list_open_windows()
else if (buttxtu=="TESTBUTTON")
    ' place testcode button here in case you want to test something

    ' If you run code that is modal here then event processing for this XDialog
    ' is held up until the modal window we created here is closed 
    ui_dlg_box("TestModal_1",<<%text%
This is a modal Xdialog box;
Opened within the event handler;
of the modeless Xdialog Timer Test box;
which creates a "child" Xdialog box;
;;;
Making it modal is not something;
one should normally do in an ;
event handler;
;;;
Notice the timer has stopped;
while this is open which indicates;
the event handling for this XDialog;
has paused;
;;;
However other XDialog boxes with;
timer events going can still run code;
that will close either any XDialog;
;;;
What happens if you close the "parent";
Xdialog prior to the "child" depends;
on options of the child's Xdialog body;
when it was started;
;;;
You also can't click on the;
Xdialog Timer Test box;
until this one is closed;
<ok>
%text%)
END IF
end
%code%

dim tmp as c
tmp=""

' Start Xdialog modeless box
tmp=ui_modeless_dlg_box(dlgtit,dlgbdy,dlgevt)
ui_dlg_box("TestModal_2",<<%text%
This is a modal Xdialog box;
Opened in the current session;
of the modeless XDialog Timer Test box;
after it was opened.;
;;;
Notice the timer is still going;
but you can't click on the;
Xdialog Timer Test box;
until you close this;
Or wait 10 seconds for the timer;
event to close this;
<ok>
%text%)

END FUNCTION

Now from the interactive editor 1st run this

XdialogTimerTest("TestModal",NOW()+20)

This will open a Modeless Xdialog box, then immediately open a Modal Xdialog box. It will keep the Modal Xdialog box open till you close it or for 10 seconds, which ever comes 1st.

After the Modal XDialog Box above is closed, run this code

ui_dlg_box("TestModal","This is a sample modal Xdialog box;<ok>")

This will open another XDialog Modal Box called "TestModal" which will close at start time + 20 seconds

If you'd like to see what happens when you run a Modal Xdialog within an event handler of an XDialog box, press the Test Code button.

Feel free to modify or experiment with other aspects of code and events.

WARNING. Changing the code, you can easily create a situation that will hang Alpha Five and require terminating with Task Manager. MAKE SURE ANY OTHER CODE OR DATA IS SAVED 1ST!!!

[G Gabriel]

Re: application timeout

Either you didn't read or more likely you read and didn't understand anything I said. It is quite clear to me from your post here and elsewhere that you don't quite understand how modal vs modeless xdlg work and I wouldn't waste any time trying to explain only to say try to close an open modal xdlg using ui_modeless_dlg_close() WITHOUT the timer event. Just try to prove your assertion that ui_modeless_dlg_close(), among other functions meant for modeless xdlg, works on modal as well. It DOES NOT.

[davidv43]

Re: application timeout

Gentlemen,

please go to your corners and let users decide what fits their practice. Alpha Five message boards are historically not subject to personal criticism.

respectfully,

dave

forgive me if this is good-natured banter masquerading as personal grudge

[davidv43]

Re: application timeout

by the way, it's clear from this thread that the issue of having some type of administrator control over loose ends is needed. Most of the major league databases like Oracle or SQL Server have maintanence functions.

Perhaps that's the message to Alpha Five development teams.

Dave

[csda1]

Re: application timeout

Hi Dave,

please go to your corners and let users decide what fits their practice. Alpha Five message boards are historically not subject to personal criticism.

Which is why I won't respond at that level and responded with

For everyone else, here is some code to try and to modify that will illustrate it for yourself.

by the way, it's clear from this thread that the issue of having some type of administrator control over loose ends is needed

By using the WAS and SQL, it doesn't have the same issue. Closing remote Alpha Five stations is something I can just about do (except for one small item, "C" Code "Dialog" Boxes) and it's been on the back burner as a utility along with background backups during operation. Cal and I have discussed it offline as well.

[davidv43]

Re: application timeout

I am using a database on a server and my users are using the runtime version to hit it. There aren't many users and speed hasn't been a big issue, so I haven't done any Network Optimization. I guess what I don't understand is when files are left open, where does Alpha Five see them as open? If I delete the .MUF file, does that make it disappear? I've been afraid to do that for fear of screwing up the fabric of time (or some equally catatrophic event).

Dave

[csda1]

Re: application timeout

I am using a database on a server and my users are using the runtime version to hit it. There aren't many users and speed hasn't been a big issue, so I haven't done any Network Optimization.

If your network is not maxed out, then that's fine.

I guess what I don't understand is when files are left open, where does Alpha Five see them as open? If I delete the .MUF file, does that make it disappear? I've been afraid to do that for fear of screwing up the fabric of time (or some equally catatrophic event).

If you can delete a .MUF or .RMUF file, nothing bad will happen. If you can't, then most likely one or more people have a lock on it.

Files can be opened by a client station and not shared (typical) and tables are typically shared. Files like Addin_Library.AEX are locked such that if you have two A5 windows open on the same machine, it can't be updated. Most code that contains table.open() closes the table at the end of the session function, but I know Cal and I never depend on it. It is almost always best to close what ever you opened and restore as much as possible prior to exit an area of code. The one exception is typically for speed.

Modal Dialog and Modal XDialog lock up the foreground User interface, so while these are open, users have no control outside the Modal Box controls.

You may find my tips on Record Locking helpful for understanding shared files like tables. For regular files, it's a bit different, but Alpha does have files that are exclusively locked, as well as those that are just read into memory