We have a long outstanding issue, which is starting to drive our customers to despair. OI just drops out back to Windows as if it were never running. This usually happens when our customers are ?dithering? over a menu option. It only ever happens in the runtime, not the development (/dv) mode (where we bypass the entry point form) and can happen several times per day per workstation.

The entry point form is an invisible window which calls a startup program from the create event. This in turn starts a login window, and based on the login calls the appropriate menu using the Dialog_Box.function. The next line in this program is an End_Dialog on the entry point form ? the assumption being that when the user closes their main menu, they want out to log out. It is like this next line of code is being executed while the Dialog Box (menu) is still open.

We have tried switching the approach so that the entry point window is an MDI frame and the login screen and menu become children. However, with this approach, over the course of about 1-2 days the whole network will slowly grind to a halt requiring the server to be rebooted to clear and begin functioning again normally ? for the next day or so.

It is as though something is wrong within our program and ?dropping out? is its own way of clearing the error before it gets too bad. By altering the program so that it can?t drop out so easily, the error seems to build up and up eventually bringing the network down.

I was wondering whether it could be something peculiar related to our early lack of understanding of events, not knowing a Return 1 from a 0 and Send_Event from Post_Event or Forward_Event etc. Is it possible to ?confuse? the event handIer by posting an event that never gets executed? Or forwarding an event that hasn?t been posted etc? I note that if I put a debug statement in the midst of my MDI event handling commuter module and then close the debugger, that click events on most buttons no longer fire, so something seems confused. I have to log out of OI and come back in to get them to fire again. The equivalent menu items will still fire successfully.

I have posted a question about this a couple of years ago, but we didn?t get anywhere with locating the problem. I assume other people don?t have this problem… Any help is appreciated. We are using OI 3.7.

Robert,

This really seems like an odd problem. It may very well be related to event code that hasn't been designed very well, but it seems odd that you don't get the same problem when running the application in development mode. My first reaction was that your customer's version of OI has been hosed. In which case I'd backup their Oengine.exe, reinstall a fresh OI, restore the application components, and then copy back in Oengine.exe. Finally, test to see if the problem continues.

FWIW, we have the same type of login scheme that you described and never have this problem.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don

Firstly, thanks for your reply. This is a tricky one and your help is appreciated. Good to know that you are using the same methodology successfully. I think the reason we don't get the problem in development mode is we almost never test run from the entry point form because the create event is perpetually running (waiting for the dialog box/main menu to close) and so we can't switch over to the System Editor and recompile - "Another process has exclusive access to the engine or the debugger has suspended execution. The current process cannot continue". So in dev mode we bypass the create event code where the End_Dialog follows the Dialog_Box.

I could perhaps have been clearer in my first post about the "dithering". Typically, the user has clicked on a dropdown menu item (for example "File") and is moving the mouse pointer down the list but hasn't yet clicked on an option when suddenly OI is gone! As far as I am aware, OI is not generating any events at this point which tends to blow my "messy events" theory out of the water.

Which leaves your suggestion that we have a messy version of OI. I can tell you that I can't get UTILITY('PRINTSETUP') to work ? it just ignores the call. I notice a post by Cameron (01/05/98) saying that the form ?PRINTSETUP? was shipped in OI 3.5 and available through SYSPROG. We do not have that form, so I wonder if we could have skipped an upgrade along the way? I also assume from the posts on the topic that no one else seems to have a problem getting ?PRINTSETUP? to work?

Robert,

I'm not sure if this is part of the problem but you said that the reason you don't go through the main entry window is because the CREATE event is perpetually running. I *assume* that once you have logged in as a valid user the CREATE event will complete its course and allow the other application windows to operate. Are you doing something different?

Otherwise, it's possible you skipped an update. More likely one update didn't quite take.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don

It appears we are doing something different… Following is the last few lines of the program called from the create event of the Entry Point Form

reply=Dialog_Box(MENU, Parent, '') ;* Run the menu we want

reply=End_Window(Parent) ;* Close the Entry Point form on completion when the Dialog_Box closes.

Thus the create event is permanently waiting for the Dialog_Box to close during the entire session… I have often wondered about the wisdom of this approach…

This is going to sound like a stupid question, but what's your network topology? We have some clients that have a similar problem and we're not to sure what it's related to. We think we have some ideas, but we don't want to spill our hand and lead you into some answers.

The Sprezzatura Group

World Leaders in all things RevSoft

Hi Sprezz

I was always taught the only stupid question was the one that was never asked.

Um? Network topology? Various and makes no difference. The problem (dropping out) will occur on a single user workstation running the development version without the /dv in the command line. The 3-4 sites that we know "grind to a halt" if we change the login style are 'hybrid mesh' running without the NL/M. Three are Novell and one is NT.

As far as I can tell, the network config doesn't seem to have a whole lot to do with it.

Robert Lee

Robert,

Whether or not this is causing your application problems I would highly suggest that you redesign this part of your application. It appears that you have different windows that will initially appear to the end user. I'm not sure if that can be handled any other way but we have one main MDI frame that is the launching point of the application. This MDI launches invisibly. During its CREATE event a user login dialog box is called. If the user enters a valid login ID then the MDI frame is allowed to become visible and there is no dialog box left running (also, BTW, our MDI frame adjusts its menus and toolbar buttons to accomodate the access definition for the current user.) If the user cancels then the MDI frame is never made visible and shuts itself down.

Based on your short description of your approach it seems that you could make your menu window a modeless dialog box (so other stuff can go on). That might be a quick way to retool without a lot of major changes.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don

Thanks for all your help. I think you have put us onto the right track.

We have looked through our archives of old OI Upgrades and find that version 3.5 is suspiciously missing. I will rebuild our whole system from the ground up after acquiring a copy of 3.5. I think this must be how our system got ""hosed"".

Didn't think we could possibly have got a single Return 0/1 wrong…

After we have done this, we will have another attempt at a more othodox log-in scheme as per your suggestion. By the way, we do require different users to start at different menus.

Robert

View this thread on the forum...