I have a tiny demo utility that shows how to use WM_COPYDATA
to remote-control my main app from a user's app.  It is just
a modal dialog that allows entry of macro commands, which
are sent to the main app.  Works great.

But some users will prefer not to get this involved with
Windows message queues and such, and would be happy with a
simple command-line version that could take a macro string
as a parameter and send it directly.  They could use this in
a standard batch file, or build up the command line and
invoke it from their HLL of choice.

This version still needs a message queue (so it can be
notified with error status, etc), just not a visible window.
I don't think there is a way to have a message queue without
a window (is there?), so the question is how to hide it, so
that it behaves to the user like a console app.  

So far, I've tried issuing ShowWindow set to SW_HIDE when
the modal queue gets the WM_INITDIALOG message, but no luck.
I'm not sure if I'm screwing something up (like maybe the
wrong handle?), or if I'm trying to do the impossible... at
least with a modal dialog.

Any help or ideas would be greatly appreciated!

Best regards,


Bob Masta
 
              DAQARTA  v5.10
   Data AcQuisition And Real-Time Analysis
              www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
    Frequency Counter, FREE Signal Generator
           Pitch Track, Pitch-to-MIDI 
         DaqMusic - FREE MUSIC, Forever!
             (Some assembly required)
     Science (and fun!) with your sound card!

On Oct 30, 11:55=A0pm, N0S...@daqarta.com (Bob Masta) wrote:
> I don't think there is a way to have a message queue without
> a window (is there?)

You can have a message queue without a window. All a message queue is
is a standard GetMessage/DispatchMessage loop. (Or similar; it might
use PeekMessage or whatever.) If you are using a modal dialog at the
moment then it will run its own message loop but nothing stops you
running your own instead.

You can post messages to a thread (rather than a window) using
PostThreadMessage. However, there is no SendThreadMessage so it's not
suitable for using WM_COPYDATA.

> so the question is how to hide it, so
> that it behaves to the user like a console app. =A0

You should not be aiming to hide the window; you should be aiming to
not show it in the first place. If you show it and then hide it it
will look bad.

I suspect the problem you're running into is that modal dialogs do
their best to be shown, even if you try to stop it, because a hidden
modal dialog would basically lock up most apps (they'd be waiting for
user input when the user can't see or interact with the dialog) and is
rarely something anyone would do intentionally.

There are ways to make modal dialogs stay hidden but I can't remember
the details. You probably shouldn't be using a modal dialog (or a
dialog for that matter) at all in this case. Just create a standard
window and don't ever show it, then run your own message loop.

It's really worth getting a book like the Petzold one if you are not
familiar with the basics of Win32 message loops etc.. None of it is
complex but it also doesn't work how you might expect it to work, so
it's worth getting a basic understanding and removing the mystery and
guesswork. At least, I found it helped me a hell of a lot.

On Sat, 30 Oct 2010 23:55:50 GMT, N0Spam@daqarta.com (Bob Masta)
wrote:

>I have a tiny demo utility that shows how to use WM_COPYDATA
>to remote-control my main app from a user's app.  It is just
>a modal dialog that allows entry of macro commands, which
>are sent to the main app.  Works great.
>
>But some users will prefer not to get this involved with
>Windows message queues and such, and would be happy with a
>simple command-line version that could take a macro string
>as a parameter and send it directly.  They could use this in
>a standard batch file, or build up the command line and
>invoke it from their HLL of choice.
>
>This version still needs a message queue (so it can be
>notified with error status, etc), just not a visible window.
>I don't think there is a way to have a message queue without
>a window (is there?), so the question is how to hide it, so
>that it behaves to the user like a console app.  
>
>So far, I've tried issuing ShowWindow set to SW_HIDE when
>the modal queue gets the WM_INITDIALOG message, but no luck.
>I'm not sure if I'm screwing something up (like maybe the
>wrong handle?), or if I'm trying to do the impossible... at
>least with a modal dialog.
>
>Any help or ideas would be greatly appreciated!
>

On the first call to ShowWindow at application startup the nCmdShow
parameter must be whatever is passed to WinMain. You must call
ShowWindow a second time to hide it. You can do this in your
InitInstance.

   ShowWindow(hWnd, nCmdShow);
   ShowWindow(hWnd, SW_HIDE);

Don't forget to send your window an IDM_EXIT message when it finishes
its work.

On Sat, 30 Oct 2010 18:56:24 -0700 (PDT), Leo Davidson
<leonudeldavidson@gmail.com> wrote:

>On Oct 30, 11:55=A0pm, N0S...@daqarta.com (Bob Masta) wrote:
>> I don't think there is a way to have a message queue without
>> a window (is there?)
>
>You can have a message queue without a window. All a message queue is
>is a standard GetMessage/DispatchMessage loop. (Or similar; it might
>use PeekMessage or whatever.) If you are using a modal dialog at the
>moment then it will run its own message loop but nothing stops you
>running your own instead.

Right, but the problem seems to be that the message loop
needs a handle.  My little utility is a client that needs to
talk to my main app, a totally separate program.  The client
can of course find the handle to the main app with
FindWindow to send the command via SendMessage with its own
handle as NULL.  It doesn't need a message loop for that.  

But the main app responds by posting a WM_USER message back
to the client, and it needs to have a handle for that.  If
the client is a simple non-window console-type app and sends
using NULL as the handle, then that's what the main app
gets... and if it tries to post back to NULL it is only
going back to itself.  I also tried having the client use
hInstance, in which case the main app sees 0x00400000 as the
handle, and still no use.  

That's why I concluded that a window is needed in order to
use a message queue.  But could I somehow assign a handle to
a simple console app, which Windows could use for this?
That would be even better than hiding the window, since then
there would also be no entry in the system tray (which takes
a surprising amount of time to display).

<snip>

>It's really worth getting a book like the Petzold one if you are not familiar with the basics of Win32 message >loops etc.. None of it is complex but it also doesn't work how you might expect it to work, so it's worth getting a >basic understanding and removing the mystery and guesswork. At least, I found it helped me a hell of a lot.

I've used Petzold for years, but I've never seen anything
this far out of the mainstream in Petzold.  Maybe if he
added another couple of thousand pages... <g>

Thanks, and best regards,



Bob Masta
 
              DAQARTA  v5.10
   Data AcQuisition And Real-Time Analysis
              www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
    Frequency Counter, FREE Signal Generator
           Pitch Track, Pitch-to-MIDI 
         DaqMusic - FREE MUSIC, Forever!
             (Some assembly required)
     Science (and fun!) with your sound card!

On Oct 31, 4:48=A0pm, N0S...@daqarta.com (Bob Masta) wrote:

> Right, but the problem seems to be that the message loop
> needs a handle. =A0My little utility is a client that needs to
> talk to my main app, a totally separate program. =A0The client
> can of course find the handle to the main app with
> FindWindow to send the command via SendMessage with its own
> handle as NULL. =A0It doesn't need a message loop for that. =A0

If you want to send/post a message to a window then obviously you need
a window handle. SendMessage and PostMessage should only be given
window handles (or a handful of special values). Don't pass instance
handles to them; it'll do nothing at best and crash something (maybe
some other program!) at worst.

If you want to post a message to a thread's message queue you don't
need a window handle; you can use PostThreadMessage which takes a
thread ID instead of a window handle.

(PostThreadMessage probably won't be useful to you *in this case*
because you can't use WM_COPYDATA with it, but it does exist for other
situations.)

FindWindow finds a window, not an application. Be careful not to
confuse windows, message queues, threads and processes. They are all
very different things, as are their handles and the APIs which use
them.



> That's why I concluded that a window is needed in order to
> use a message queue. =A0But could I somehow assign a handle to
> a simple console app, which Windows could use for this?

If you want to send message between processes without using a window
then you shouldn't be using WM_COPYDATA in the first place (as it
requires a window). You'd be better off using another IPC mechanism
COM, or a shared pipe, memory mapped file, or whatever. (Take your
pick.)

> That would be even better than hiding the window, since then
> there would also be no entry in the system tray (which takes
> a surprising amount of time to display).

As I said, you don't need to hide the window; just avoid showing it in
the first place. There are thousands of apps which launch and have no
(initially) visible user interface. The problem you're having is that
something is showing your window; if it isn't you calling ShowWindow
(or similar) directly then it must be something else, such as the
dialog manager. (Using a modal dialog probably isn't a good idea, for
this reason, although it can be kudged around.)

You could put a breakpoint in your code in window's message proc to
see what is causing it to be shown if you want to investigate that.


> I've used Petzold for years, but I've never seen anything
> this far out of the mainstream in Petzold. =A0Maybe if he
> added another couple of thousand pages... <g>

Petzold explains message loops in detail. This is all mainstream stuff
for Win32.

On Sun, 31 Oct 2010 09:34:47 -0700 (PDT), Leo Davidson
<leonudeldavidson@gmail.com> wrote:

>On Oct 31, 4:48=A0pm, N0S...@daqarta.com (Bob Masta) wrote:
>
>> Right, but the problem seems to be that the message loop
>> needs a handle. =A0My little utility is a client that needs to
>> talk to my main app, a totally separate program. =A0The client
>> can of course find the handle to the main app with
>> FindWindow to send the command via SendMessage with its own
>> handle as NULL. =A0It doesn't need a message loop for that. =A0
>
>If you want to send/post a message to a window then obviously you need
>a window handle. SendMessage and PostMessage should only be given
>window handles (or a handful of special values). Don't pass instance
>handles to them; it'll do nothing at best and crash something (maybe
>some other program!) at worst.

Turns out the instance handle is really just the offset of
the code in memory (0x00400000).

>If you want to post a message to a thread's message queue you don't
>need a window handle; you can use PostThreadMessage which takes a
>thread ID instead of a window handle.
>
>(PostThreadMessage probably won't be useful to you *in this case*
>because you can't use WM_COPYDATA with it, but it does exist for other
>situations.)
>
>FindWindow finds a window, not an application. Be careful not to
>confuse windows, message queues, threads and processes. They are all
>very different things, as are their handles and the APIs which use
>them.

In my case it's a pretty safe bet to find the application,
since the app doesn't allow multiple instances, and the
window name is not likely to be used by another app.

>> That's why I concluded that a window is needed in order to
>> use a message queue. =A0But could I somehow assign a handle to
>> a simple console app, which Windows could use for this?
>
>If you want to send message between processes without using a window
>then you shouldn't be using WM_COPYDATA in the first place (as it
>requires a window). You'd be better off using another IPC mechanism
>COM, or a shared pipe, memory mapped file, or whatever. (Take your
>pick.)

I don't mind a window, just not a *visible* window. (See
below.)  I chose  WM_COPYDATA from among all the other IPCs
because it seemed to be the simplest approach.  It's fast
and  low overhead for the main app, and if the user wants to
incorporate this method into his own code (presumably with a
window already) his overhead is trivial.

>> That would be even better than hiding the window, since then
>> there would also be no entry in the system tray (which takes
>> a surprising amount of time to display).
>
>As I said, you don't need to hide the window; just avoid showing it in
>the first place. There are thousands of apps which launch and have no
>(initially) visible user interface. 

Yep, that's what I finally did.  I was originally hoping to
avoid all the class and window code overhead (by using a
modal dialog as the main window), but I couldn't seem to
avoid showing it, or at least showing it in the system tray.
But an unshown "normal" window works fine.  And only 2500
bytes total, so not too bad.

> The problem you're having is that
>something is showing your window; if it isn't you calling ShowWindow
>(or similar) directly then it must be something else, such as the
>dialog manager. (Using a modal dialog probably isn't a good idea, for
>this reason, although it can be kudged around.)
>
>You could put a breakpoint in your code in window's message proc to
>see what is causing it to be shown if you want to investigate that.
>
>> I've used Petzold for years, but I've never seen anything
>> this far out of the mainstream in Petzold. =A0Maybe if he
>> added another couple of thousand pages... <g>
>
>Petzold explains message loops in detail. This is all mainstream stuff
>for Win32.

He does indeed.  What I was referring to as non-mainstream
was the idea of a Windows message loop without a window.  Of
course, the reason it's not mainstream is that it's not
possible!   <g>

I could have saved myself (and you!) a lot of trouble if I
hadn't been so convinced that there must be a shortcut
approach.  Sorry!

Best regards,


Bob Masta
 
              DAQARTA  v5.10
   Data AcQuisition And Real-Time Analysis
              www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
    Frequency Counter, FREE Signal Generator
           Pitch Track, Pitch-to-MIDI 
         DaqMusic - FREE MUSIC, Forever!
             (Some assembly required)
     Science (and fun!) with your sound card!

On Oct 31, 7:07=A0pm, N0S...@daqarta.com (Bob Masta) wrote:
> I could have saved myself (and you!) a lot of trouble if I
> hadn't been so convinced that there must be a shortcut
> approach. =A0Sorry!

But that's where great ideas come from :)

Sometimes :(

On Oct 31, 11:07=A0pm, N0S...@daqarta.com (Bob Masta) wrote:

> He does indeed. =A0What I was referring to as non-mainstream
> was the idea of a Windows message loop without a window. =A0Of
> course, the reason it's not mainstream is that it's not
> possible! =A0 <g>

It *is* possible to have a message loop without a window.

Windows need message loops but message loops do not need windows.

There's a trivial example here:

http://en.wikipedia.org/wiki/Message_loop_in_Microsoft_Windows

You could use PostThreadMessage to talk to an app which ran a message
loop like that and which did not ever create a window. (The message
loop would need to be modified slightly to check for incoming thread
messages, but it'd still never need to create a window.)

On Sun, 31 Oct 2010 20:43:58 -0700 (PDT), Leo Davidson
<leonudeldavidson@gmail.com> wrote:

>On Oct 31, 11:07=A0pm, N0S...@daqarta.com (Bob Masta) wrote:
>
>> He does indeed. =A0What I was referring to as non-mainstream
>> was the idea of a Windows message loop without a window. =A0Of
>> course, the reason it's not mainstream is that it's not
>> possible! =A0 <g>
>
>It *is* possible to have a message loop without a window.
>
>Windows need message loops but message loops do not need windows.
>
>There's a trivial example here:
>
>http://en.wikipedia.org/wiki/Message_loop_in_Microsoft_Windows

>You could use PostThreadMessage to talk to an app which ran a message
>loop like that and which did not ever create a window. (The message
>loop would need to be modified slightly to check for incoming thread
>messages, but it'd still never need to create a window.)

Interesting idea, but the above example doesn't explain that
you do need a message queue, plus a handle for the external
app to post the messages to.  You get both of those when you
create a window, and the external app can use FindWindow to
get the handle.  Is there something analogous for finding a
thread in another app?  Or can FindWidow do that as well?
(Note that a thread doesn't have a message queue until its
first call to a User or GDI function.  The MSDN topic on
PostThreadMessage explains how to deal with this.)

The other problem with PostThreadMessage is that (as you
pointed out earlier) it can't send WM_COPYDATA.  So assuming
you use wParam as an identifier, that leaves only one dword
of data per message.  Still, this could be a useful method
to know about, if there is a way to find the thread handle
from an external app.

Best regards,


Bob Masta
 
              DAQARTA  v5.10
   Data AcQuisition And Real-Time Analysis
              www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
    Frequency Counter, FREE Signal Generator
           Pitch Track, Pitch-to-MIDI 
         DaqMusic - FREE MUSIC, Forever!
             (Some assembly required)
     Science (and fun!) with your sound card!

On Nov 1, 1:53=A0pm, N0S...@daqarta.com (Bob Masta) wrote:


> but the above example doesn't explain that
> you do need a message queue

The message queue is implicit from the fact there is a message pump
loop. In the example, the queue is created as soon as GetMessage is
called. (CreateWindow isn't the only thing that triggers a message
queue to be created.)

One caveat with PostThreadMessage is that you have to ensure the
target thread has already triggered creation of its message queue. If
you try to post it a message before then it will fail.


> plus a handle for the external app to post the messages to.
>=A0You get both of those when you create a window, and the
> external app can use FindWindow to get the handle.
> Is there something analogous for finding a thread in another
> app?

You can find a named process but AFAIK (outside of debuggers) Windows
has no concept of "named threads". In most situations where you'd want
to post to a thread's message queue something which already knew the
thread's ID (e.g. the thread itself or the thing that created the
thread) would have passed it to you as a parameter. Plenty of other
ways it could be found, though.


>=A0Or can FindWidow do that as well?

No, FindWindow only finds windows; processes and threads are alien to
it (and would never be returned as an HWND).


> The other problem with PostThreadMessage is that (as you
> pointed out earlier) it can't send WM_COPYDATA. =A0So assuming
> you use wParam as an identifier, that leaves only one dword
> of data per message. =A0Still, this could be a useful method
> to know about, if there is a way to find the thread handle
> from an external app.

Yeah, for cross-process stuff that DWORD often isn't enough. (For
cross-thread stuff within a single process, you could pass a pointer
to something. Of course, you have to be careful about who frees that
memory.)

I don't think the PostThreadMessage approach is a good fit for what
you're doing right now but it can be useful in other situations, so I
figured it was worth mentioning.

On Oct 30, 11:55=A0pm, N0S...@daqarta.com (Bob Masta) wrote:

> This version still needs a message queue (so it can be
> notified with error status, etc), just not a visible window.

Going back to the original question, there's something I forgot all
about until now but which probably fits your needs completely:

You can create a message-only window (using HWND_MESSAGE as the
parent).

http://msdn.microsoft.com/en-us/library/ms632599%28VS.85%29.aspx#message_on=
ly

I'll quote the relevant section (linked above) as MSDN has been a
flakey recently (though seems fine this morning):

--8<--
A message-only window enables you to send and receive messages. It is
not visible, has no z-order, cannot be enumerated, and does not
receive broadcast messages. The window simply dispatches messages.

To create a message-only window, specify the HWND_MESSAGE constant or
a handle to an existing message-only window in the hWndParent
parameter of the CreateWindowEx function. You can also change an
existing window to a message-only window by specifying HWND_MESSAGE in
the hWndNewParent parameter of the SetParent function.

To find message-only windows, specify HWND_MESSAGE in the hwndParent
parameter of the FindWindowEx function. In addition, FindWindowEx
searches message-only windows as well as top-level windows if both the
hwndParent and hwndChildAfter parameters are NULL.
-->8--

FWIW, I have a feeling HWND_MESSAGE only works on Windows 2000 and
above, but I may be misremembering.

On Wed, 3 Nov 2010 02:13:10 -0700 (PDT), Leo Davidson
<leonudeldavidson@gmail.com> wrote:

>On Oct 30, 11:55=A0pm, N0S...@daqarta.com (Bob Masta) wrote:
>
>> This version still needs a message queue (so it can be
>> notified with error status, etc), just not a visible window.
>
>Going back to the original question, there's something I forgot all
>about until now but which probably fits your needs completely:
>
>You can create a message-only window (using HWND_MESSAGE as the
>parent).
>
>http://msdn.microsoft.com/en-us/library/ms632599%28VS.85%29.aspx#message_on=
>ly
>
>I'll quote the relevant section (linked above) as MSDN has been a
>flakey recently (though seems fine this morning):
>
>--8<--
>A message-only window enables you to send and receive messages. It is
>not visible, has no z-order, cannot be enumerated, and does not
>receive broadcast messages. The window simply dispatches messages.
>
>To create a message-only window, specify the HWND_MESSAGE constant or
>a handle to an existing message-only window in the hWndParent
>parameter of the CreateWindowEx function. You can also change an
>existing window to a message-only window by specifying HWND_MESSAGE in
>the hWndNewParent parameter of the SetParent function.
>
>To find message-only windows, specify HWND_MESSAGE in the hwndParent
>parameter of the FindWindowEx function. In addition, FindWindowEx
>searches message-only windows as well as top-level windows if both the
>hwndParent and hwndChildAfter parameters are NULL.
>-->8--
>
>FWIW, I have a feeling HWND_MESSAGE only works on Windows 2000 and
>above, but I may be misremembering.

Thanks for this excellent tip!  This looks like the way to
go.  I wasn't able to find anything definitive on the
minimum Windows version for HWND_MESSAGE, but XP and later
would probably cover all my likely users.

Best regards,


Bob Masta
 
              DAQARTA  v5.10
   Data AcQuisition And Real-Time Analysis
              www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
    Frequency Counter, FREE Signal Generator
           Pitch Track, Pitch-to-MIDI 
         DaqMusic - FREE MUSIC, Forever!
             (Some assembly required)
     Science (and fun!) with your sound card!

On Tue, 2 Nov 2010 12:23:14 -0700 (PDT), Leo Davidson
<leonudeldavidson@gmail.com> wrote:

>On Nov 1, 1:53=A0pm, N0S...@daqarta.com (Bob Masta) wrote:
>
>
>> but the above example doesn't explain that
>> you do need a message queue
>
>The message queue is implicit from the fact there is a message pump
>loop. In the example, the queue is created as soon as GetMessage is
>called. (CreateWindow isn't the only thing that triggers a message
>queue to be created.)

I had never heard that GetMessage created the queue, but
that might explain the problem I had when I tried this
earlier.  (See the first of my 10-31-10 posts.)  I was using
SendMessage to send WM_COPYDATA before starting the message
loop to watch for the response.  (Seemed logical!)  But the
problem was that SendMessage could only send NULL as its
handle, and since it wasn't in a window (or queue)  then
NULL is all that my main app received as the sender's
handle.  Of course, reponding to NULL didn't do anything.

So to make this work, I guess the initial SendMessage would
have to be given from inside the message loop... somehow.
(That assumes that if it used NULL as its handle, Windows
would fill in the handle it had presumably assigned to the
queue.)

Aye, but there's the rub!  How to send the initial message
from inside a message loop that shouldn't be getting any
messages other than a *response* to the initial message.
Is there some kind of initialization message that this queue
would get when it started?  Without that, there seems no way
to send it anything.

Best regards,


Bob Masta
 
              DAQARTA  v5.10
   Data AcQuisition And Real-Time Analysis
              www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
    Frequency Counter, FREE Signal Generator
           Pitch Track, Pitch-to-MIDI 
         DaqMusic - FREE MUSIC, Forever!
             (Some assembly required)
     Science (and fun!) with your sound card!