Sending messages between windows

23 Apr 2010 8:15 AM

Brian Cryer

I'm working on migrating an application written in Delphi to VB.Net. The
current application makes use of a number of Windows/Forms each of which
send messages via the windows API to a "master" form. Given what these
windows are doing the overall design makes sense. Sending and handling
messages in this way is a doddle for Delphi. Is there an equivalent
mechanism available when using VB.Net? I'd rather not drop down to the
windows api to send messages - and even if I did I'm not sure how to capture
events at the recipient end. Any suggestions?

TIA.

--
Brian Cryer
www.cryer.co.uk/brian

23 Apr 2010 10:07 AM

AMercer

It will be simple if (1) all the forms are running in the same executable, ie
IPC is not required, and (2) the app is single threaded. What you need to do
is add some public events/subs/functions to the master form. If you add
events, you also add their event handlers. In the worker forms, you will
raise the events or call the subs/functions. The workers need an object
reference to the master form, and you can put that in a public module:

Public Module SomeName
Public MyMasterForm As MasterForm
End Module

In the master form's load event, do MyMasterForm=Me, and now all the worker
forms can access public members of your master form, eg
MyMasterForm.Whatever(...)

If your app is multithreaded, you will need to thread protect the calls to
the master form. Generally, this is done by 'thread invoke', and it is well
documented. The gist of the issue is that Windows/.NET require that
some/most operations in a form be carried out on the form's original thread
(ie the thread that created the form), and 'thread invoke' causes this to
happen.

Show quoteHide quote

"Brian Cryer" wrote:

> I'm working on migrating an application written in Delphi to VB.Net. The
> current application makes use of a number of Windows/Forms each of which
> send messages via the windows API to a "master" form. Given what these
> windows are doing the overall design makes sense. Sending and handling
> messages in this way is a doddle for Delphi. Is there an equivalent
> mechanism available when using VB.Net? I'd rather not drop down to the
> windows api to send messages - and even if I did I'm not sure how to capture
> events at the recipient end. Any suggestions?
>
> TIA.
> --
> Brian Cryer
> www.cryer.co.uk/brian
>
> .
>

23 Apr 2010 11:16 AM

Brian Cryer

Hi. Thanks for the suggestion. The app is multithreaded (but I'm used to
working with multithreaded aps, so that isn't an issue), and whilst it does
have multiple open forms these are all in the same executable. So the event
model you suggest would work.

I do have one reservation. The original application used PostMessage rather
than SendMessage, the important thing about PostMessage was that it could
send the message and then carry on with whatever processing it was doing
without having to wait. Now presumably events are blocking? Wait, I suppose
that this doesn't matter it just means adding my own queue so the different
threads can post their message/event on the queue and then continue.

You've put me on the right track. Thanks.

--
Brian Cryer
www.cryer.co.uk/brian

Show quoteHide quote

"AMercer" <AMer***@discussions.microsoft.com> wrote in message
news:2CF7A1AB-4A67-4D40-A2B3-B60DE8612B3A@microsoft.com...
> It will be simple if (1) all the forms are running in the same executable,
> ie
> IPC is not required, and (2) the app is single threaded. What you need to
> do
> is add some public events/subs/functions to the master form. If you add
> events, you also add their event handlers. In the worker forms, you will
> raise the events or call the subs/functions. The workers need an object
> reference to the master form, and you can put that in a public module:
>
> Public Module SomeName
> Public MyMasterForm As MasterForm
> End Module
>
> In the master form's load event, do MyMasterForm=Me, and now all the
> worker
> forms can access public members of your master form, eg
> MyMasterForm.Whatever(...)
>
> If your app is multithreaded, you will need to thread protect the calls to
> the master form. Generally, this is done by 'thread invoke', and it is
> well
> documented. The gist of the issue is that Windows/.NET require that
> some/most operations in a form be carried out on the form's original
> thread
> (ie the thread that created the form), and 'thread invoke' causes this to
> happen.
>
> "Brian Cryer" wrote:
>
>> I'm working on migrating an application written in Delphi to VB.Net. The
>> current application makes use of a number of Windows/Forms each of which
>> send messages via the windows API to a "master" form. Given what these
>> windows are doing the overall design makes sense. Sending and handling
>> messages in this way is a doddle for Delphi. Is there an equivalent
>> mechanism available when using VB.Net? I'd rather not drop down to the
>> windows api to send messages - and even if I did I'm not sure how to
>> capture
>> events at the recipient end. Any suggestions?
>>
>> TIA.
>> --
>> Brian Cryer
>> www.cryer.co.uk/brian
>>
>> .
>>

23 Apr 2010 12:39 PM

Brian Cryer

Having done a little research, your tip about "thread invoke" was an ace.
Most of my development up to now has been on web development so I wasn't
aware of this little gem. Thanks.

--
Brian Cryer
www.cryer.co.uk/brian

Show quoteHide quote

"AMercer" <AMer***@discussions.microsoft.com> wrote in message
news:2CF7A1AB-4A67-4D40-A2B3-B60DE8612B3A@microsoft.com...
> It will be simple if (1) all the forms are running in the same executable,
> ie
> IPC is not required, and (2) the app is single threaded. What you need to
> do
> is add some public events/subs/functions to the master form. If you add
> events, you also add their event handlers. In the worker forms, you will
> raise the events or call the subs/functions. The workers need an object
> reference to the master form, and you can put that in a public module:
>
> Public Module SomeName
> Public MyMasterForm As MasterForm
> End Module
>
> In the master form's load event, do MyMasterForm=Me, and now all the
> worker
> forms can access public members of your master form, eg
> MyMasterForm.Whatever(...)
>
> If your app is multithreaded, you will need to thread protect the calls to
> the master form. Generally, this is done by 'thread invoke', and it is
> well
> documented. The gist of the issue is that Windows/.NET require that
> some/most operations in a form be carried out on the form's original
> thread
> (ie the thread that created the form), and 'thread invoke' causes this to
> happen.
>
> "Brian Cryer" wrote:
>
>> I'm working on migrating an application written in Delphi to VB.Net. The
>> current application makes use of a number of Windows/Forms each of which
>> send messages via the windows API to a "master" form. Given what these
>> windows are doing the overall design makes sense. Sending and handling
>> messages in this way is a doddle for Delphi. Is there an equivalent
>> mechanism available when using VB.Net? I'd rather not drop down to the
>> windows api to send messages - and even if I did I'm not sure how to
>> capture
>> events at the recipient end. Any suggestions?
>>
>> TIA.
>> --
>> Brian Cryer
>> www.cryer.co.uk/brian
>>
>> .
>>

23 Apr 2010 10:51 AM

Patrice

Hello,

..NET exposes WndProc.

The MessageWindow class is available but apparently only in the Windows CE
..NET Framework so you could expose the Windows API using this same model
(http://msdn.microsoft.com/en-us/library/microsoft.windowsce.forms.messagewindow_members(v=VS.90).aspx)
or you could mimic how it is done in Delphi to ease the transition.

Not sure about why it has to be this way, but my personal preference would
be to drop using windows messages if this is not to work with predefined
messages. If this is an app specific messages you could just expose this
using good "old" methods (forms are just classes) with possibly a central
dispatcher...

--
Patrice

"Brian Cryer" <not.here@localhost> a écrit dans le message de groupe de

discussion : #pJjp0r4KHA.1***@TK2MSFTNGP06.phx.gbl...
Show quoteHide quote

> I'm working on migrating an application written in Delphi to VB.Net. The
> current application makes use of a number of Windows/Forms each of which
> send messages via the windows API to a "master" form. Given what these
> windows are doing the overall design makes sense. Sending and handling
> messages in this way is a doddle for Delphi. Is there an equivalent
> mechanism available when using VB.Net? I'd rather not drop down to the
> windows api to send messages - and even if I did I'm not sure how to
> capture events at the recipient end. Any suggestions?
>
> TIA.
> --
> Brian Cryer
> www.cryer.co.uk/brian
>

23 Apr 2010 11:18 AM

Brian Cryer

Hi Patrice.

I was hoping to avoid using WndProc. But your comment regarding a "central
dispatcher" (not quite what I will use) together with AMercer's reply have
given me sufficient ideas to know how to proceed.

Thanks.

--
Brian Cryer
www.cryer.co.uk/brian

Show quoteHide quote

"Patrice" <http://scribe-en.blogspot.com/> wrote in message
news:enw4jLt4KHA.6104@TK2MSFTNGP05.phx.gbl...
> Hello,
>
> .NET exposes WndProc.
>
> The MessageWindow class is available but apparently only in the Windows CE
> .NET Framework so you could expose the Windows API using this same model
> (http://msdn.microsoft.com/en-us/library/microsoft.windowsce.forms.messagewindow_members(v=VS.90).aspx)
> or you could mimic how it is done in Delphi to ease the transition.
>
> Not sure about why it has to be this way, but my personal preference would
> be to drop using windows messages if this is not to work with predefined
> messages. If this is an app specific messages you could just expose this
> using good "old" methods (forms are just classes) with possibly a central
> dispatcher...
>
> --
> Patrice
>
> "Brian Cryer" <not.here@localhost> a écrit dans le message de groupe de
> discussion : #pJjp0r4KHA.1***@TK2MSFTNGP06.phx.gbl...
>> I'm working on migrating an application written in Delphi to VB.Net. The
>> current application makes use of a number of Windows/Forms each of which
>> send messages via the windows API to a "master" form. Given what these
>> windows are doing the overall design makes sense. Sending and handling
>> messages in this way is a doddle for Delphi. Is there an equivalent
>> mechanism available when using VB.Net? I'd rather not drop down to the
>> windows api to send messages - and even if I did I'm not sure how to
>> capture events at the recipient end. Any suggestions?
>>
>> TIA.
>> --
>> Brian Cryer
>> www.cryer.co.uk/brian
>>
>

24 Apr 2010 4:41 AM

Mr. Arnold

Brian Cryer wrote:

> I'm working on migrating an application written in Delphi to VB.Net. The
> current application makes use of a number of Windows/Forms each of which
> send messages via the windows API to a "master" form. Given what these
> windows are doing the overall design makes sense. Sending and handling
> messages in this way is a doddle for Delphi. Is there an equivalent
> mechanism available when using VB.Net? I'd rather not drop down to the
> windows api to send messages - and even if I did I'm not sure how to
> capture events at the recipient end. Any suggestions?
>
> TIA.

This is a simple C#.Net example. You can convert it over to VB.Net.
<http://www.c-sharpcorner.com/UploadFile/thmok/SendingWindowsMessageinCSharp11262005042819AM/SendingWindowsMessageinCSharp.aspx>

The other solution would be to use Windows Communication Foundation to
send messages between Master.form (WCF service host) and Client.forms
(WCF clients).