Make messageBox dissapear straight after Yes/No

  • Thread starter Thread starter jez
  • Start date Start date
J

jez

Kinda difficult to explain the problem. Basically I'm using the
signatureCapture from HoodCanalSystems. It captures the signature by
capturing the part of the screen where the signature control is located.
This means that when I have a MessageBox on top of that signatureControl,
the MessageBox will be captured as well. You're in with me so far?

Good:) so, this is my problem : I ask for confirmation from the user with a
MessageBox Yes/No if no email address was entered. If the user clicks Yes
then it should save the signature. It does it fine, the only problem is that
the MessageBox does not dissapear straight away. I.e. it's still on the
screen when the signature is being saved (i checked it out in debug mode).

Is there any way to refresh the screen or make that MessageBox go away as
soon as the user clicked either Yes or No. I.e. I don't want to wait until
the end of the method for the MessageBox to dissapear.

Thanks !

jez
 
jez said:
Kinda difficult to explain the problem. Basically I'm using the
signatureCapture from HoodCanalSystems. It captures the signature by
capturing the part of the screen where the signature control is located.
This means that when I have a MessageBox on top of that signatureControl,
the MessageBox will be captured as well. You're in with me so far?

Good:) so, this is my problem : I ask for confirmation from the user with a
MessageBox Yes/No if no email address was entered. If the user clicks Yes
then it should save the signature. It does it fine, the only problem is that
the MessageBox does not dissapear straight away. I.e. it's still on the
screen when the signature is being saved (i checked it out in debug mode).

Is there any way to refresh the screen or make that MessageBox go away as
soon as the user clicked either Yes or No. I.e. I don't want to wait until
the end of the method for the MessageBox to dissapear.

Well, you could try calling Application.DoEvents. I'm not a big fan of
it myself, but it might just work.

Another alternative you should seriously consider is that if the
signature takes any significant amount of time to save, you should do
that in a different thread.
 
With out meaning to hi-jack the thread... why don't you like DoEvents?

Paul
 
Paul said:
With out meaning to hi-jack the thread... why don't you like DoEvents?

I find re-entrancy nasty, basically. Also, if you're trying to simulate
multi-threading by calling DoEvents everywhere, you don't know exactly
how often to do it, etc - and if you *do* have a blocking call
anywhere, it's not going to help then.

So while I think it might be okay in some situations, I try to steer
clear of it in general.
 
Jon,

thanks for that! It did indeed solve my problem :) and thanks for the quick
reply!

Ok, so it's all good for this application but just wondering, what could
happen with my application that I don't want by using Application.DoEvents()
?
 
jez said:
thanks for that! It did indeed solve my problem :) and thanks for the quick
reply!

Ok, so it's all good for this application but just wondering, what could
happen with my application that I don't want by using Application.DoEvents()
?

Well, if you use DoEvents in the wrong place, you could end up with re-
entrancy problems. If you use it in a situation where you have blocking
calls in your code, it won't achieve the illusion of multi-threading
that it's usually used for.

I believe on the desktop framework there are other potential problems
regarding message pumps, but I can't remember the details.
 
alrighty, thanks for that precious info! I'll make sure that next time I use
a different thread.. it's just that at the moment I haven't yet tried to use
mulithreading on the CF.. it's still an undiscovered domain for me. Probs
for my next project.. at uni:P.
 
Been quickly through it, looks really interesting! The first half basically
summarizes what I've been doing at uni in Java:P It's definitely helpful to
have the same thing in C#! I wonder when they're going to decide to start
teaching C# instead of Java. Anyways, thanks for the link! Will definitely
print it out and read it !
 
Back
Top