Closing window via ole causes warning sound

AusMarkB

Attempting to get to the bottom of an issue which is possibly just a nuisance rather than a real problem.
I use the srp button extensively but whenever I use one to close a window the Windows warning/exclamation sound bings.
Everything seems to work but I can't help but feel that something is amiss and certainly users must wonder why they're being binged at.

Scenarios

Action	Warning Sound
OI button click event executes close	No
OLE button click event executes post_event - click of the above OI button	Yes
OLE button click event executes post_event - window close	Yes

I got into the habit of using post_event to an OI button when the window is a dialog box but the bing sound happens regardless of using this approach and even when the window is a "window" or an "mdi_child".
Tried debugging but the sound doesn't occur until after the last line of code is executed so I'm looking for suggestions.

KevinFournier

What is does your QUALIFY_EVENT statement look like for the button's click event?

AusMarkB

NoParamsToPass = 10 ; // Max Qualifier = '' If eventoff then // Want to turn processing off for this event Qualifier = false$ end else Qualifier<1> = 1 Qualifier<2> = NoParamsToPass:wwa_star$:@appid<1>:wwa_star$:'OLE.OLECONTROL.OIWIN':wwa_star$ Qualifier<4> = synchronous ; * synch end retVal = Send_Message(ctrlentid, 'QUALIFY_EVENT', Event, Qualifier)

the synchronous value is false$

KevinFournier

Any Promoted CLOSE event logic?

AusMarkB

Nope. Only promoted event is the ole event that this qualifies to.
And I step that through and it all just goes through relatively harmless and then bings once we're done.

DonBakke

Actually, this is expected...or at least it's always been an issue when using OLE event handlers to close forms. I believe the "ding" is actually this error occurring in the background:

ENG0040: RUN_EVENT, line 1. The labeled common variable has been freed and is no longer valid.

OLE event handlers don't always get fully resolved and removed from memory even when a Post_Event is used to call another non-OLE event handler. This can occur because there are things that can "slip" in.

Can I assume you are using a commuter module to handle the OLE event? If you don't need to run code then you can just hook the OLE event to the Close window QuickEvent:


If you need to run code, then in your OLE event handler set the TIMER property to 1 : @FM : 1. Then hook the TIMER event to the Close window QuickEvent.

If you need both code in your OLE event handler and you are already using the TIMER event, then just set a UDP and have the TIMER event check this UDP. If set, then have the TIMER event do a Post_Event to a hidden OI button that calls the Close window QuickEvent.

AusMarkB

The timer event works a treat.

I've been ignoring that issue for so long. On occasion the debugger pops up with that error message but it's inconsistent and infrequent and generally only with the same window whereas I close pretty much every window the same way. Some ding and some don't or perhaps they all do and I've just tuned out. For that reason I thought the two were different things.

Now to give some consideration on how to apply the same principle to dialog boxes where I want to return data via End_dialog. Though that might not be an issue. I know the window that generally displays the debugger message is a dialog box but I think it only occurs when they click the cancel button rather than when they save and return data.