Dialog Shadow

Posted by Roger Blanchard on 14-Nov-2012 07:17

I am running into an issue where when using ShowDialog there is a shadow of the dialog after the dialog closes if I am making any type of SYNC call.

For example,

WAIT-FOR rDialog:ShowDialog () SET oRes.

RUN Proc1 ON hAppServer.

The shadow will not disappear until the call to the AppServer completes. The same thing happens if I am making a SYNC call to an activeX control.

I spoke with PTS and they said to use the following;

WAIT-FOR rDialog:ShowDialog ().

oRes = rDialog:DialogResult.

As I though that did nothing at all.

What I did to solve was add PROCESS EVENTS after the WAIT-FOR. I am told that using PROCESS EVENTS in GUI for .NET is not a good thing. If that is the case how can I get rid of the dialog shadow?

Any insight would be great.

All Replies

Posted by asthomas on 14-Nov-2012 07:18

I am not in the office until November 19th 2012. I will not be checking my mail and phone on a regular basis, but will reply to your mail as soon as I can.

If you need support from appSolutions, please send your mails to support@app-solutions.com.

If you need Roundtable support, please send mails to :

support-europe@roundtable-tsms.com.

Jeg er væk fra kontoret indtil den 19. november, og checker ikke mail og telefon regelmæssigt. Jeg vil dog svare på din mail så snart som muligt.

Hvis du har behov for support, kontakt venligst support@app-solutions.com, så vender vi tilbage så snart det er muligt.

Administrative henvendelser kan ske til : admin@app-solutions.com.

Med venlig hilsen / Regards

Thomas Hansen

appSolutions a/s

Posted by robw@hltool.com on 14-Nov-2012 07:23

Can you replicate the problem on multiple workstations? Is it possibly a Windows 7 Aero setting gone awry?

Posted by Roger Blanchard on 14-Nov-2012 07:36

I have duplicated on Win7 and WinXP.

Posted by rbf on 14-Nov-2012 08:26

rblanchard wrote:

What I did to solve was add PROCESS EVENTS after the WAIT-FOR. I am told that using PROCESS EVENTS in GUI for .NET is not a good thing. If that is the case how can I get rid of the dialog shadow?

Any insight would be great.

Who told you PROCESS EVENTS is not a good thing in GUI for .NET? Why?

Does it solve your issue?

Posted by Roger Blanchard on 14-Nov-2012 08:34

PTS recommended to NOT use PROCESS EVENTS. It DOES solve my issue with the shadow but I have seen PROCESS EVENTS crash my app.

For example, in my POS app we print to a receipt print using an ActiveX control. We send the receipt lines ASYNCHRONOUSLY and when the printer is finished the ActiveX control fires a StatusUpdate event. If a .NET dialog such as a MESSAGE box is displayed when the StatusUpdate fires it will crash the app if a PROCESS EVENTS is called from the StatusUpdate event.

We have removed all PROCESS EVENTS from our client side code and no longer see any crashes.

Posted by danielStafford on 14-Nov-2012 16:24

I didn't know about process events crashing clients. I have a customer who is very frustrated with freeze-ups. Other customers never complain.

In my POS app I use PROCESS EVENTS to handle various problems I couldn't find a solution for. I just revisited sales.cls and saw that I could replace PROCESS EVENTS with a pause(.5) NO-MESSAGE (Any less time doesn't work). This obviously isn't a solution, but is interesting.

What did work was, prior to my need for PROCESS EVENTS and just before I did a reposition-to-rowid on the same query, I was closing the query with armsTrxQuery:query-close() and then reopening it with a different query-prepare(). I replaced the close method with:

    armsTrxQuery:query-prepare("preselect each eArmsTrx where rowid(eArmsTrx) = to-rowid('0x0')").  /* I think I got this hint from Mike Fechner */

    armsTrxQuery:query-open().

Now I don't need PROCESS EVENTS, at lease in this bit of code.

So, closing a query looks to be problematic!

Thanks for the alert Roger.

This thread is closed