Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Non-DDE IPC?
TheNullinator:
I've attached a 7z archive of the diff file for the DDE replacement. I've tested it quite a bit on both Windows ME and XP (both ANSI and unicode) and haven't come across any more problems.
I had to modify associations.cpp to detect and remove DDE information from the association keys in the registry or Windows thinks Code::Blocks still handles DDE messages. The only other modified files are app.cpp and app.h.
[attachment deleted by admin]
thomas:
Tested. First, it tossed a "cannot find file" error at me every time. After manually removing all the stale DDE keys from the registry (the automatic uninstall does not seem to catch them all), that error was gone.
Although writing the window ID to the registry gives me a bit of a pain in the stomach, it seems to work perfectly for some files.
For some? Yes, unluckily... While all source files go into one instance just fine, XRC files and headers are opened in a separate instance. Worse yet, if I select 10 XRC files and select "open" from Explorer's context menu, 10 instances of Code::Blocks launch in parallel, each opening one file...
So... too early for thumbs up yet, but it looks like a start :)
TheNullinator:
--- Quote from: thomas on April 07, 2006, 10:02:30 am ---Tested. First, it tossed a "cannot find file" error at me every time. After manually removing all the stale DDE keys from the registry (the automatic uninstall does not seem to catch them all), that error was gone.
--- End quote ---
Hmm, I'll look into that a bit more.
--- Quote from: thomas on April 07, 2006, 10:02:30 am ---Although writing the window ID to the registry gives me a bit of a pain in the stomach, it seems to work perfectly for some files.
--- End quote ---
Yeah, that is a rather dodgy thing to be doing :) but it did the job at the time. I'm looking into other ways of achieving the same result.
--- Quote from: thomas on April 07, 2006, 10:02:30 am ---For some? Yes, unluckily... While all source files go into one instance just fine, XRC files and headers are opened in a separate instance.
--- End quote ---
I don't have any issues with header files but do experience some with XRCs now you mention it. I'll look into that one more, too.
--- Quote from: thomas on April 07, 2006, 10:02:30 am ---Worse yet, if I select 10 XRC files and select "open" from Explorer's context menu, 10 instances of Code::Blocks launch in parallel, each opening one file...
--- End quote ---
Oh man, I didn't even think of testing that. :roll: :)
--- Quote from: thomas on April 07, 2006, 10:02:30 am ---So... too early for thumbs up yet, but it looks like a start :)
--- End quote ---
A start it is. :) And thanks for the pointers to issues you encountered I hadn't come across. :) I'll go have a look at them and see what I can do.
thomas:
I still think that using a memory mapped file should work fine (could get rid of the registry stuff, and makes it cross-platform-able, too).
It is possible to open a named MMF and query the error message if it was already created (works the same way as a named mutex!).
There is even a complete wrapper class available to handle memory mapped files and shared memory areas: http://www.naughter.com/memmap.html
It may not be 100% what you need and might need some tweaking, but I guess it is quite good for a start.
One would also need a kind of linked list or queue that does not allocate memory on the heap, but is happy to live inside a dedicated memory area, as well as a mutex to protect access to it. That's probably the hardest part.
Then, you could start up and open the file mapping (or a named shared memory section, doesn't matter). If it does *not* exist, then you are the first instance. Write your window handle *here* (not into the registry).
If it *does* exist, you are (obviously) not the first one to use it, so you lock the mutex, append your data to the linked list, and release the mutex.
Then fire off a notification to the window ID which you can find in the shared memory and quit.
Instead of using window IDs and sending messages, one could also use a sepmaphore to signal that new data has arrived, this is somewhat nicer.
The main instance of Code::Blocks could either launch a separate thread that blocks on the semaphore, or simply query the semaphore's state (non-blocking) from inside OnIdle. The latter solution would delay opening files slightly if the PC is under heavy load, but that is not necessarily a bad thing. Actually, it is even a very desirable feature, since this avoids adding more and more load when the machine is already thrashing anyway.
If using things like mmap, mutexes, and semaphores, we could implement the very same functionality for Windows and Linux and only need to change a few lines in each.
TheNullinator:
Hmm, sounds pretty good. :) I'll have a look into it now.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version