Its killing me! Allocating memory in software!

**NSFW** · 06-26-2009, 10:22 PM

Originally Posted by colin

I need to be able to call ONE function (sendmessage for example) with any type of data. It has to be able to process Integers, Strings, Chars, Pointers, StringLists (delphi thing), HID_Devices, TSongs (custom classes).

Lots of ways to skin that cat. Declare a base TPluginMessage, for example, and pass those around. Derive types from TPluginMessage that add the extra stuff you need. I don't know if Delphi has run-time type information; if it does not, TPluginMessage needs a field that indicates which derived type it really is.

So:

if (currentMessage.Type == MessageType.SongMessage)
{
TSongMessage songMessage = (TSongMessage) currentMessage;
Play(songMessage);
}

...or whatever. I haven't done much Delphi and that little bit was several years ago, so you'll have to translate some of the syntax.

**colin** · 06-27-2009, 09:47 PM

Originally Posted by ClockWorK

If you don't call GlobalLock, you will never have a true pointer. Seriously. But maybe you never even need a real pointer. If you call these at the load of your app, and store them in global variables, I don't see why it wouldn't work.

AppStart:
Allocate Memory and store handle into global variable.
Lock Memory and store pointer into global variable.

AppEvents:
Use the global variables to access the allocated memory.

AppClose:
Unlock and free the allocated memory

From MSDN:

GMEM_FIXED
0x0000
Allocates fixed memory. The return value is a pointer.

GMEM_ZEROINIT
0x0040
Initializes memory contents to zero.

GPTR
0x0040
Combines GMEM_FIXED and GMEM_ZEROINIT.

Originally Posted by malcom2073

Does delphi not have a Variant type?

Yes, but you need to convert things to a variant first I think? Its hard to use, really.

Originally Posted by NSFW

So that is what's different from what I described.

You need a way to allocate memory and control when it's released. In C++ you'd use "new" and I'm guessing Delphi has something similar. If you use Local/GlobalAlloc, put the handle into your queued structure, so that the code that pulls structures from the queue can also pass the handle to Local/GlobalFree (I think that's what it's called...) after passing the structure to all of the plugins.

Delphi has a NEW function, but the problem is you have to know what you're creating. You cant specify a size and expect Delphi to create the memory.

Originally Posted by NSFW

Lots of ways to skin that cat. Declare a base TPluginMessage, for example, and pass those around. Derive types from TPluginMessage that add the extra stuff you need. I don't know if Delphi has run-time type information; if it does not, TPluginMessage needs a field that indicates which derived type it really is.

So:

if (currentMessage.Type == MessageType.SongMessage)
{
TSongMessage songMessage = (TSongMessage) currentMessage;
Play(songMessage);
}

...or whatever. I haven't done much Delphi and that little bit was several years ago, so you'll have to translate some of the syntax.

No way. I did try that however, I made 10 different Broadcast functions each with different parameters, it didn't work and was a bigger pain than this is.

**NSFW** · 06-27-2009, 11:59 PM

Originally Posted by colin

Delphi has a NEW function, but the problem is you have to know what you're creating. You cant specify a size and expect Delphi to create the memory.

But you do know what you're creating when you allocate the memory, right?

No way.

No way, what?

**colin** · 06-28-2009, 08:17 AM

Originally Posted by NSFW

But you do know what you're creating when you allocate the memory, right?

Sort of. The program runs off of this broadcast system, so it will broadcast hundreds, if not thousands of messages. I can't say that every similar message will share a data type. Sometimes, the "INIT_DONE" broadcast will have a string attached to it, sometimes it will have an integer. I need a function that doesn't care. Just copies it blindly and sends it back blindly too.

Originally Posted by NSFW

No way, what?

I tried that, it was a pain and it didnt work right. The problem is just that there are SO many broadcasts, I can't be doing comparisons for every message because there are too many. It will also be harder in the future because if I don't anticipate a data type, I can't pass it later on for plugins. For example, HIDDevice -- I would have completely forgotten about that. What about when I finish writing the CD player units and stuff, I'll probably have to pass over device handles and CD objects. Can't predict that.

**TMF** · 06-28-2009, 08:24 AM

Follow this link. http://delphi.about.com/od/windowssh...m_copydata.htm

This shows how to use the special Windows Message WM_COPYDATA to pass data from one program to another.

**TMF** · 06-28-2009, 08:26 AM

I'm not real active on this forum, but I program Delphi full time and have been doing it since Turbo Pascal 1.0. Someday I may have to write my own front-end.

**Curiosity** · 06-28-2009, 09:11 AM

Are the plugins seperate processes or within the same process like a DLL? There's no need for WM_COPYDATA in the same process.

SendMessage is synchronous and PostMessage is async. When using SendMessage, the message is sent and replied before SendMessage returns, so you can deallocate the memory immediately after the call. I normally use PostMessage then free the data after use so there's no waiting.

I do a lot of serialized programming too, and use the windows messaging system to handle it but in C++ and there are so many ways to accomplish what you're trying to do. Like define each message type as WM_USER+n or have every structure type pointer in your main message structure with a 'Type' variable that defines what it is, or union or void pointer. That's kind of how variants work. You should try not to allocate a struct with another allocated struct within it though. It gets too complicated.

So a basic idea:
MyData = (MyDataType1) allocate(sizeof MyDataType1)
fill it in
PostMessage(window, WM_USER+1, 1, MyData)

Then when you recieve the WM_USER+1, cast LPARAM as your data, use it, free it.

**colin** · 06-28-2009, 09:52 AM

Looks like SendMessage is the way to go right now. Ill check it all out and hope for the best. Guess Ill email myself all the files and try to get it done at work today

I wanted to avoid it and everything, but I guess I'm stuck with it.

**colin** · 06-29-2009, 09:45 PM

Okay, I'm having trouble with this again!

How would it work? It won't follow a QUEUE system at all if I use SendMessage!

Lets pretend the message WM_INIT gets sent to 7 units.

Unit1: does its thing
Unit2: does its thing
Unit3: broadcasts WM_DRIVEATTACHED
...
Units 1 - 7 would now get WM_DRIVEATTACHED before they got WM_INIT or else the functions wouldnt be able to return!
...
Unit4: etc...