[Openroad-users] Preventing code running during debug

[Collins, William - ES/EW]

In case anyone is still interested in this. We are able to handle the the frame deactivate event with code that is always in place. Using CurFrame.ObjectSource, only a few of the attributes are available in an image versus source running in debug from the Workbench. The attribute we happen to use is AlterBy, if you are running an image, it will be empty (e.i., ''), from the Workbench it will contain an actual value. So:

IF CurFrame.ObjectSource.AlterBy NOT = ''
THEN
    /* we are running in debug */
ELSE
    /* we are running an image */
ENDIF;

There may still be some cases where this doesn't always produce the desired result, depending on what you're doing in the DEACTIVE code block.

Bill

________________________________
From: openroad-users-bounces at peerlessit.com [mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Kim Ginnerup
Sent: Thursday, November 01, 2007 3:30 AM
To: International OpenROAD Users; Openroad-Users
Subject: Re: [Openroad-users] Preventing code running during debug

The problem is "Break on Next"
It is a bit irritating.
I normally set a break point instead, this way the childkeydown event will run as expected and you app will stop at the following break point.

There is a similar problem with the windows activate and deactivate events because every time the debugger gets focus it triggers the windows deactivate.
I haven't figured out to get passed this problem without comment out the event block when debug is needed.
(Haven't tested this in OR 2006 to see if it still is a problem.)

Kim
________________________________
Fra: openroad-users-bounces at peerlessit.com [mailto:openroad-users-bounces at peerlessit.com] På vegne af Bloomfield, Martin (PSD)
Sendt: 26. oktober 2007 10:51
Til: Openroad-Users
Emne: [Openroad-users] Preventing code running during debug


Following the problems I was having the other week with exiting multi-line entry fields in a tablefield, I managed to work around this using a combination of a childkeydown (to detect shift keys) and childkeypress events.  This is now working as I would like, allowing the users to press tab or enter to exit the field.

However, as a consequence of implementing the childkeydown event, I am no longer able to debug my application as when I do a Debug | Break on Next Statement, every keypress causes the childkeydown event to run (as expected) but no code runs after the event exits.  Does anyone know if it is possible to prevent this event running when in debug mode, but have it running at all other times?  I know I could comment out the event but this stops it running all the time & I would have to remember to re-activate it before imaging the application.

For info I'm using OR4.1 SP2 on Windows XP.

Thanks,

Martin Bloomfield.
_________________________________________________
Application Developer & Database Administrator
IT Branch,
Pesticides Safety Directorate
YORK

Email: martin.bloomfield at psd.defra.gsi.gov.uk<mailto:martin.bloomfield at psd.defra.gsi.gov.uk>
Website: www.pesticides.gov.uk<http://www.pesticides.gov.uk>

P Save a tree... please don't print this e-mail unless you really need to

Department for Environment, Food and Rural Affairs (Defra)



This email and any attachments is intended for the named recipient only.

If you have received it in error you have no authority to use, disclose,

store or copy any of its contents and you should destroy it and inform

the sender.

Whilst this email and associated attachments will have been checked

for known viruses whilst within Defra systems we can accept no

responsibility once it has left our systems.

Communications on Defra's computer systems may be monitored and/or

recorded to secure the effective operation of the system and for other

lawful purposes.

________________________________
This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.peerlessit.com/pipermail/openroad-users/attachments/20071128/a6cf328c/attachment-0001.html