Global atoms - Just a query

[MRe]

Hi,

Reading about atoms in MSDN Library and it says that the global atom
table can contain up to 37 entries, which isn't many, for global, so I
wrote a little atom spy type app to list/add/delete all global atoms,
and I noticed no such limiting 37 entry limit (using XP, does this
matter).
Am I reading something wrong here, 'cause I'm thinking of using
global atoms, but if a 37 entry limit applies (even if on a different
OS), it's a bit of a gamble that there'll be space, no?

Thanks
MRe

[Sten Westerback]

"MRe" <m...@dublin.ie> wrote in message
news:2e8985ea.04021...@posting.google.com...

Where did you read about such a limit? In my references and on
http://msdn.microsoft.com/library i find references to 37 only
regarding local atoms and that limit can be changed with InitAtomTable().

One would think that all the global atoms used by the system (Window
Classes, DDE data format strings etc) would easily bump into any
37 limit... but i haven't notices such problems.

Anyway... are you sure atoms are the best way to do what
you need? For what? I have needed them directly only for DDE.

- Sten

[MRe]

Thanks for the reply

> Where did you read about such a limit? In my references and on
> http://msdn.microsoft.com/library i find references to 37 only
> regarding local atoms and that limit can be changed with InitAtomTable().

It's on an MSDN CD I got some years ago, apparently this has been
updated.

> Anyway... are you sure atoms are the best way to do what
> you need? For what? I have needed them directly only for DDE.

Well, I was trying to use DDE, but it wasn't working out; all sorts of
crashes, including a couple of system-wide freezing (requiring a
reboot). I've been rewriting the code so many times over the last week
using different approaches (and the hours of debugging each one,
arrgh), I figured, screw it, global atom will rescue me. All I want is
to pass two strings to a hook DLL across a process boundary - I'm very
close to considering using a char array in a shared section!

Worse thing is, I think I may have figured out what the problem with
the DDE was, but I'm so PO'd with it now, I just want it to die!

Thanks again
MRe

[Norman Bullen]

Perhaps you could use WM_COPYDATA?

Norm

[MRe]

Hmmm, WM_COPYDATA--why was I not informed of this earlier! That would
have made life so much easier in previous projects; fortunately, for
my current project, it complicates matters [maybe].

I need to send this to a hook DLL (that's attached to an app I didn't
write) and I don't want that app to process the message; will it be
possible to prevent the application that is hooked from receiving this
message, (all reading I've done today has suggested that it cannot be
stopped (a WH_CALLWNDPROC hook could be stopped in 16-bit Windows but
not Win32 (why?)))

If it could be stopped before reaching the hooked application, it
would be perfect!

Thanks for the reply
MRe

[Craig Kelly]

You could create a hidden window in the hook DLL to receive the message. If
you used a wacky, er, unique class name for your window, then you could
discover all the windows of that type at run time and target them.

Craig

[Norman Bullen]

MRe wrote:
> Hmmm, WM_COPYDATA--why was I not informed of this earlier!

Perhaps because you never presented this problem to me? ;>)

A hidden window, as Craig suggests, or even appropriately subclassing
one of the existing windows is probably a good way to go.

Norm

[MRe]

<Sigh> . . . of course!

Thank you Craig and Norm
MRe