Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community

At 05 NOV 2001 01:10:21PM Jocelyn Amon wrote:

I am just new to OI and I cannot find any method of interupting a program and regaining control. This is extremely useful when I get a program loop which is not that uncommon. In fact I would think such a function would be vital!

A right-hand click on the task bar will freeze all OI screens which I can then remove with ctrl-alt-del/End Task. But then I cannot re-run OI without re-booting my computer.

After reading the documentation and scanning this discussion group I still cannot find a solution. So, can anyone help? The answer is probably something so obvious I have just overlooked it.


At 05 NOV 2001 01:17PM [url=http://www.sprezzatura.com" onMouseOver=window.status=Click here to visit our web site?';return(true)]The Sprezzatura Group[/url] wrote:

Not all programs may be broken into BUT if the program you are attempting to stop will allow you to (for example if it Yields()) you can click on the OpenEngine icon then click the debugger button. This frequently will invoke the debugger and you may now just either close the program or use the debugger to set an exit condition.

The Sprezzatura Group

World Leaders in all things RevSoft


At 05 NOV 2001 01:32PM Jocelyn Amon wrote:

So, my only option if my program loops is a reboot? Tell me this isn't so! I've already had to do this at least 10 times as I'm working on a complex bit of code.


At 05 NOV 2001 02:16PM Don Miller - C3 Inc. wrote:

Jocelyn

It's as much the nature of Windows as it is in OI. It's due to to asynchronous processing such that a task is fired up and then Open Engine simply processes it. Unless the task Yields time to windows, there's no way to break into it. MS-DOS was much more straightforward. A running program had "focus" and could respond to keystrokes. There's no similar analog in windows unless you program it. For example:

Loop

..do some useful work (or useless if you wish)

 Call Yield()
 Until Done

Repeat

If you do this, then you can get to OpenEngine on your task bar and enable the debugger. Examine variables, single step, terminate the process, etc.

You should be aware that in earlier versions of OI, calling Yield can corrupt system variables @RECORD, @ID, @DICT, etc. So you might want to write a stored procedure like:

Subroutine ShieldYield(void)

Save_Rec=@RECORD

Save_ID =@ID

Save_Dict=@DICT

Call Yield() ;* let other processes get control

@RECORD=Save_Rec

@ID =Save_ID

@DICT =Save_Dict

Return

Sprezz's site has a discussion of this in S/ENL.

Don


At 05 NOV 2001 02:51PM Robert Lee wrote:

Jocelyn

Just to make sure we are not missing something obvious - have you discovered the DEBUG statement? Forgive my ignorance of ARev, but I think they had it there too???

Another trick if you get into a crash situation is to close the engine before closing the other OI components. You can then usually rerun OI without getting the error message which necessitates rebooting.

I occasionally get myself into a situation where I have to reboot but not too frequently. The worst can be symbolic dictionary items as the debugger doesn't work there, but these days I put anything longer than a couple of lines into a function which gets around that problem.

Hope it helps

Robert Lee


At 06 NOV 2001 05:14PM Paul Rule wrote:

Jocelyn, If you're using Windows 2000 you can enable the "Run In separate memory space" option in the icon properties. If you do this, then most of the time when you close down OI you don't have to reboot.


At 12 NOV 2001 01:36PM Richard Hunt wrote:

I kinda like the way OI handles the "break key" interrupt (or no break key). See, it lets me controll it. I use a "hot key" and the "yield()" command.

I put the "yield()" command exactly where it is safe to interupt the routine. So now, when the user wants to "break out", all they do is click a menu option that activates the "hot key" and poof… the routine is interupted with a message verifying that the user really wants to interupt the routine.

With a little help from "common" variables, and a check of the common variables right after the "yield()" command, the routine then closes down safely.

What a blessing to be able to control the break key so effectively!

View this thread on the forum...

  • third_party_content/community/commentary/forums_nonworks/9bdae06ae84b9e7d85256afb0063d374.txt
  • Last modified: 2023/12/28 07:40
  • by 127.0.0.1