[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.vb.general.discussion

Window Move Lock

BeeJ

2/12/2012 3:45:00 PM

What is the best way to lock a window in place?

Why? I notice that when I move a window around, the processing seems to
halt until I have released the window.
I have noticed that some of the MS apps lock the window while running.

Lock in the sense of not being able to move the window.
A Cancel button is still active.

A few of my apps have processing that is time sensitive so I am hoping
this will help (but not totally cure) interruptions. Anyway I want to
try this to see the advantages/disadvantages.

Are there techniques to allow processing while the window is moving?
What things can be done to help ensure that processing marches on at
the desired pace? I currently use timer controls and API timer and
most time critical process I put into ActiveX EXEs etc.

Thanks
45 Answers

ralph

2/12/2012 7:41:00 PM

0

On Sun, 12 Feb 2012 07:44:46 -0800, BeeJ <nospam@spamnot.com> wrote:

>What is the best way to lock a window in place?
>
>Why? I notice that when I move a window around, the processing seems to
>halt until I have released the window.
>I have noticed that some of the MS apps lock the window while running.
>
>Lock in the sense of not being able to move the window.
>A Cancel button is still active.
>
>A few of my apps have processing that is time sensitive so I am hoping
>this will help (but not totally cure) interruptions. Anyway I want to
>try this to see the advantages/disadvantages.
>
>Are there techniques to allow processing while the window is moving?
>What things can be done to help ensure that processing marches on at
>the desired pace? I currently use timer controls and API timer and
>most time critical process I put into ActiveX EXEs etc.
>

Simply catch the Move messages.
(And/or any of many assorted messages fired when a Window is moved. Or
perhaps slap up a simpler modal dialog.)

However ...

A VB application consists of two threads, a main UI thread and a
second 'application' (for want of a better name) thread. Messages
arrive via the Forms engine. It is difficult to separate the two given
that Windows and VB are event-driven.

You mentioned that you use timers. That suggests why "processing seems
to halt" while a Window is moving. Additional messages (including
Paint, often one of the more time consuming events) are added to the
message queue. But one needs to know more about what and where these
"processes" are running, or definitely more information than what you
have provided.

Also it may be interesting to know how you are measuring these
"processes". What makes you think they or their "pace" was *stopped*
or *paused* because the Main UI thread received work, ie. there had to
be some kind of 'release' or the the Main UI thread wouldn't even run.
[Consider why you need a [Cancel] button for a further explaination.
<g>]

Reducing the number of events and reducing the amount of time spent
handling an event will definitely improve any application depending on
events, thus freezing the window will likely help. Also you may need
to revisit your application's entire event handling.

You really need so many timers?
Do you really need to be using different kinds of timers?

Remember for most Windows applications and VB applications in
particular - you can engineer for "real quick", but never for "real
time".

-ralph

unknown

2/12/2012 8:35:00 PM

0

"ralph" <nt_consulting64@yahoo.net> wrote in message
news:4g0gj7pp07ptp0bpkhioph8pcgdi3o01qo@4ax.com...
> Simply catch the Move messages.
> (And/or any of many assorted messages fired when a Window is moved. Or
> perhaps slap up a simpler modal dialog.)
>
> However ...
>
> A VB application consists of two threads, a main UI thread and a
> second 'application' (for want of a better name) thread. Messages
> arrive via the Forms engine. It is difficult to separate the two given
> that Windows and VB are event-driven.

I think you were trying to say something else, or perhaps referring to other
languages, but VB is single threaded. When the form is moved, it enters into
a modal loop(WM_ENTERSIZEMOVE/WM_EXITSIZEMOVE), so it seems as if the
application has two message queues, and doesn't do much until the move has
ended.

mm

2/13/2012 12:21:00 AM

0

On 12/02/2012 12:44 p.m., BeeJ wrote:
> What is the best way to lock a window in place?
>
> Why? I notice that when I move a window around, the processing seems to
> halt until I have released the window.
> I have noticed that some of the MS apps lock the window while running.
>
> Lock in the sense of not being able to move the window.
> A Cancel button is still active.
>
> A few of my apps have processing that is time sensitive so I am hoping
> this will help (but not totally cure) interruptions. Anyway I want to
> try this to see the advantages/disadvantages.
>
> Are there techniques to allow processing while the window is moving?
> What things can be done to help ensure that processing marches on at the
> desired pace? I currently use timer controls and API timer and most time
> critical process I put into ActiveX EXEs etc.
>
> Thanks

In the property window of the form:

Moveable = False

mm

2/13/2012 12:32:00 AM

0

On 12/02/2012 09:21 p.m., Eduardo wrote:
>
> In the property window of the form:
>
> Moveable = False

And if you still want to allow the user to move the form, you can
replace the default title bar with a picturebox and do something like this:

Dim mY As Long
Dim mX As Long

Private Sub Picture1_MouseDown(Button As Integer, Shift As Integer, X As
Single, Y As Single)
mY = Y
mX = X
End Sub

Private Sub Picture1_MouseMove(Button As Integer, Shift As Integer, X As
Single, Y As Single)
If Button = 1 Then
Me.Move Me.Left + X - mX, Me.Top + Y - mY
End If
End Sub

ralph

2/13/2012 12:54:00 AM

0

On Sun, 12 Feb 2012 15:34:50 -0500, "Farnsworth" <nospam@nospam.com>
wrote:

>"ralph" <nt_consulting64@yahoo.net> wrote in message
>news:4g0gj7pp07ptp0bpkhioph8pcgdi3o01qo@4ax.com...
>> Simply catch the Move messages.
>> (And/or any of many assorted messages fired when a Window is moved. Or
>> perhaps slap up a simpler modal dialog.)
>>
>> However ...
>>
>> A VB application consists of two threads, a main UI thread and a
>> second 'application' (for want of a better name) thread. Messages
>> arrive via the Forms engine. It is difficult to separate the two given
>> that Windows and VB are event-driven.
>
>I think you were trying to say something else, or perhaps referring to other
>languages, but VB is single threaded. ...

No actually I meant exactly what I said. A VB Application after
startup consists, at a minimum, of two threads. "Single-threaded" and
its cousin "single threaded apartments" does not mean there is only
one thread, it means only that one thread can run at a time.

But you are correct in noting that wasn't where I really needed to go,
nor all that edifying for the topic at hand, as the simple analogy of
a single path of execution is sufficient.


> ... When the form is moved, it enters into
>a modal loop(WM_ENTERSIZEMOVE/WM_EXITSIZEMOVE), so it seems as if the
>application has two message queues, and doesn't do much until the move has
>ended.
>

It has always been in this "modal loop". <g>

That is the essence of a Windows GUI program as everything runs from a
message (event) pump and returns to the pump for the next
message/event and thus the next procedure/s to run , ie a loop.

-ralph

David Youngblood

2/13/2012 2:06:00 PM

0

"BeeJ" <nospam@spamnot.com> wrote in message
>
> Lock in the sense of not being able to move the window.
> A Cancel button is still active.
>

You can remove (or disable) the Move menu item from the system menu.
Example to remove and restore,

Private Declare Function GetSystemMenu Lib "user32" ( _
ByVal hwnd As Long, _
ByVal bRevert As Long) As Long

Private Declare Function DeleteMenu Lib "user32" ( _
ByVal hMenu As Long, _
ByVal nPosition As Long, _
ByVal wFlags As Long) As Long

Private Declare Function DrawMenuBar Lib "user32" ( _
ByVal hwnd As Long) As Long

Private Const MF_BYCOMMAND = &H0&
Const SC_MOVE = &HF010

Private Sub Command1_Click()
'* Remove 'Move' menu item
Dim hMenu As Long
hMenu = GetSystemMenu(hwnd, False)
DeleteMenu hMenu, SC_MOVE, MF_BYCOMMAND
DrawMenuBar hwnd
End Sub

Private Sub Command2_Click()
'* Restore menu items
GetSystemMenu hwnd, True
DrawMenuBar hwnd
End Sub

Karl E. Peterson

2/13/2012 8:40:00 PM

0

ralph was thinking very hard :
> On Sun, 12 Feb 2012 15:34:50 -0500, "Farnsworth" <nospam@nospam.com>
> wrote:
>
>> "ralph" <nt_consulting64@yahoo.net> wrote in message
>> news:4g0gj7pp07ptp0bpkhioph8pcgdi3o01qo@4ax.com...
>>> Simply catch the Move messages.
>>> (And/or any of many assorted messages fired when a Window is moved. Or
>>> perhaps slap up a simpler modal dialog.)
>>>
>>> However ...
>>>
>>> A VB application consists of two threads, a main UI thread and a
>>> second 'application' (for want of a better name) thread. Messages
>>> arrive via the Forms engine. It is difficult to separate the two given
>>> that Windows and VB are event-driven.
>>
>> I think you were trying to say something else, or perhaps referring to other
>> languages, but VB is single threaded. ...
>
> No actually I meant exactly what I said. A VB Application after
> startup consists, at a minimum, of two threads.

Hmmm, not according to Taskmgr. I just fired off a half-dozen or so,
and found that there were anywhere from 1 to 5 threads, with no readily
apparent commonalities I could put my finger on. For an example of a
truly single-threaded sample, see either EXE in...

http://vb.mvps.org/samp...

--
..NET: It's About Trust!
http://vfre...

ralph

2/13/2012 10:06:00 PM

0

On Mon, 13 Feb 2012 12:39:47 -0800, Karl E. Peterson <karl@exmvps.org>
wrote:

>ralph was thinking very hard :
>> On Sun, 12 Feb 2012 15:34:50 -0500, "Farnsworth" <nospam@nospam.com>
>> wrote:
>>
>>> "ralph" <nt_consulting64@yahoo.net> wrote in message
>>> news:4g0gj7pp07ptp0bpkhioph8pcgdi3o01qo@4ax.com...
>>>> Simply catch the Move messages.
>>>> (And/or any of many assorted messages fired when a Window is moved. Or
>>>> perhaps slap up a simpler modal dialog.)
>>>>
>>>> However ...
>>>>
>>>> A VB application consists of two threads, a main UI thread and a
>>>> second 'application' (for want of a better name) thread. Messages
>>>> arrive via the Forms engine. It is difficult to separate the two given
>>>> that Windows and VB are event-driven.
>>>
>>> I think you were trying to say something else, or perhaps referring to other
>>> languages, but VB is single threaded. ...
>>
>> No actually I meant exactly what I said. A VB Application after
>> startup consists, at a minimum, of two threads.
>
>Hmmm, not according to Taskmgr. I just fired off a half-dozen or so,
>and found that there were anywhere from 1 to 5 threads, with no readily
>apparent commonalities I could put my finger on. For an example of a
>truly single-threaded sample, see either EXE in...
>
>http://vb.mvps.org/samp...

Ok. Fine with me.

-ralph

Karl E. Peterson

2/13/2012 10:17:00 PM

0

ralph has brought this to us :
> On Mon, 13 Feb 2012 12:39:47 -0800, Karl E. Peterson <karl@exmvps.org>
> wrote:
>
>> ralph was thinking very hard :
>>> On Sun, 12 Feb 2012 15:34:50 -0500, "Farnsworth" <nospam@nospam.com>
>>> wrote:
>>>
>>>> "ralph" <nt_consulting64@yahoo.net> wrote in message
>>>> news:4g0gj7pp07ptp0bpkhioph8pcgdi3o01qo@4ax.com...
>>>>> Simply catch the Move messages.
>>>>> (And/or any of many assorted messages fired when a Window is moved. Or
>>>>> perhaps slap up a simpler modal dialog.)
>>>>>
>>>>> However ...
>>>>>
>>>>> A VB application consists of two threads, a main UI thread and a
>>>>> second 'application' (for want of a better name) thread. Messages
>>>>> arrive via the Forms engine. It is difficult to separate the two given
>>>>> that Windows and VB are event-driven.
>>>>
>>>> I think you were trying to say something else, or perhaps referring to
>>>> other languages, but VB is single threaded. ...
>>>
>>> No actually I meant exactly what I said. A VB Application after
>>> startup consists, at a minimum, of two threads.
>>
>> Hmmm, not according to Taskmgr. I just fired off a half-dozen or so,
>> and found that there were anywhere from 1 to 5 threads, with no readily
>> apparent commonalities I could put my finger on. For an example of a
>> truly single-threaded sample, see either EXE in...
>>
>> http://vb.mvps.org/samp...
>
> Ok. Fine with me.

Holy crap, man, that's *not* how the Internet works! WTH??? <g>

Heh, seriously, what gives with some pretty simple VB apps having 3, 4,
5 threads, and others limited to just 1? (Anyone?)

--
..NET: It's About Trust!
http://vfre...

Bob Butler

2/13/2012 11:27:00 PM

0


"Karl E. Peterson" <karl@exmvps.org> wrote in message
news:jhc24g$e4d$1@dont-email.me...
> ralph has brought this to us :
<cut>
>> Ok. Fine with me.
>
> Holy crap, man, that's *not* how the Internet works! WTH??? <g>
>
> Heh, seriously, what gives with some pretty simple VB apps having 3, 4, 5
> threads, and others limited to just 1? (Anyone?)

the web browser control adds threads; what's in the 'pretty simple' app that
is showing multiple threads?