Prev: Debugging Tricks : Going Blank
Next: disable mdi form resize
From: Bee on 3 Mar 2010 20:56
I need to encapsulate the calling routine and return since this process gets
called at six different places in the app to return propeties to six
different controls.
Thanks for the input.

"Helmut Meukel" wrote:

>
> "Bee" <Bee(a)discussions.microsoft.com> schrieb im Newsbeitrag
> news:3663D214-7D32-49D1-930D-1ACDC57511B3(a)microsoft.com...
> >I do not want the calling form code to proceed until the user makes a choice
> > on frmX.
> > I do not want a modal form using vbModal because I cannot get past other
> > issues using a vbModal form.
> >
> > frmX.Show ' this opens the form
> > ' after the frmX _Load event execution continues here.
> > ' but I do not want it to be until the user makes a choice.
> >
> > So I put the loop in frmX to wait there until the choice is made.
> >
> > What way would you implement this?
> >
>
> Break your code in two parts:
> 1) all code including the line
> frmX.Show ' this opens the form
> End Sub
>
> 2) the second part - processing the data from frmX
> put into a new Property Let routine of the calling form.
>
> Public Property Get X_Data(vData as Variant)
> ' here goes the code processing the Data from frmX
> End Property
>
> 3) in frmX:
> when the user has entered his data and clicks ok
>
> frmMain.X_Data = myNewData
>
> I used a Variant for this example, if there are more than one
> value use an array...
> Or instead of a Property use a Public Sub with all your values
> as parameters.
>
> With your idea of a loop you slow down the execution of
> the code in frmX.
>
> HTH,
>
> Helmut.
>
> .
>
From: Bee on 3 Mar 2010 21:00
That's a new one on me. Still more to learn.

"Jim Mack" wrote:

> Bee wrote:
> > I do not want the calling form code to proceed until the user makes
> > a choice on frmX.
> > I do not want a modal form using vbModal because I cannot get past
> > other issues using a vbModal form.
> >
> > frmX.Show ' this opens the form
> > ' after the frmX _Load event execution continues here.
> > ' but I do not want it to be until the user makes a choice.
> >
> > So I put the loop in frmX to wait there until the choice is made.
> >
> > What way would you implement this?
>
> One problem with making the new form non-modal is that if you wait
> nicely in the original form, you allow UI actions there. So you may
> also need to disable that form, or some elements of it.
>
> You could wait in a 'loose' DoEvents loop, using Sleep or PeekMessage
> within it. Inside the loop, check the status of the form you opened,
> and exit when it's no longer active.
>
> A sneaky way to do that might be:
>
> Do
> Sleep 50
> Loop While DoEvents > 1
>
> But you'll probably need something less generic.
>
> --
> Jim
>
> .
>
From: Karl E. Peterson on 3 Mar 2010 21:09
Bee wrote:
> After I posted I tried doing just that in a .bas module to centralize the
> process since this routine gets called fro six different places and returns a
> parameter related to six different control properties.
>
> So ...
> Sleep is OK compared to CreateWaitableTimer?

I think so, generally speaking. I'd use short intervals, though, so
your app doesn't seem unresponsive.

> DoEvents has what negativness if not needed?

Well, not having it in there may prevent your app from querying its own
message queue.

--
..NET: It's About Trust!
http://vfred.mvps.org


From: Paul Clement on 3 Mar 2010 22:54
On Wed, 3 Mar 2010 17:54:01 -0800, Bee <Bee(a)discussions.microsoft.com> wrote:

� After I posted I tried doing just that in a .bas module to centralize the
� process since this routine gets called fro six different places and returns a
� parameter related to six different control properties.
�
� So ...
� Sleep is OK compared to CreateWaitableTimer?
� DoEvents has what negativness if not needed?
� I have nothing that needs real speed at this time in th eapp.
�
� Thanks

If you use the Sleep function then you will probably want to use DoEvents as
well. Otherwise, your app may appear to be non-responsive because its message
queue will not be processed while the app thread is suspended.

BTW, if I remember correctly I believe that DoEvents makes a call to Sleep with
a value of 0 (giving up the app's time slice).

I still think the timer method is preferable.

Paul
~~~~
Microsoft MVP (Visual Basic)
From: MM on 4 Mar 2010 04:36
On Wed, 3 Mar 2010 15:34:07 -0800, Bee <Bee(a)discussions.microsoft.com>
wrote:

>I do not want the calling form code to proceed until the user makes a choice
>on frmX.
>I do not want a modal form using vbModal because I cannot get past other
>issues using a vbModal form.

You can hide the modal form temporarily, do whatever stuff you need
where the modalness would barf, then show the form modal again. It's
what I've just done with my music app. I had added a form
"Build-A-Chord" with vbModal. Then I realised I could not play on the
virtual keyboard, another form, to record the notes to build the
chord! So I hit upon the idea of hiding frmBuildAChord, with a
suitable explanation to the user why this is happening, pop up another
little form with KeepOnTop = True (a little function of mine that I
keep handy to add whenever needed) to make it look like a modal form
with just an OK button on it, the user 'plays' the virtual keyboard
and whatever notes are played are added to a data structure, then the
user clicks OK when finished adding notes to the chord and
frmBuildAChord is once again shown with vbModal. Works a treat.

MM
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Debugging Tricks : Going Blank
Next: disable mdi form resize