• Welcome to Theos PowerBasic Museum 2017.

News:

Attachments are only available to registered users.
Please register using your full, real name.

Main Menu

A long history for a perhaps short solution...

Started by Norbert Doerre, March 22, 2011, 12:13:59 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Norbert Doerre

The philosophy of my cad program dates from the early 80s, when autocad published their first trial. I should tell this before i start to explain my current "problem". You might imagine how often and how much the code has been changed in the mean time, mostly and only according to UNIX5/DOS/WINOWS compatibility.
It is nevertheless running still fine and even used by authorities in Germany.
So far, so good.
The principle Windows concept of the program consists of EXEs and in average, depending from user's needs, 30 DLLs all interacting and with their small portions of mostly technical code simply updatable.
An EXE may contain a systab-control for user's settings, as well as DLLs may offer their special dialog. I programatically change the content of a systab control just for user's current needs. So i can reduce the amount of controls.
DLLs needing a settings tab can use a free tab area inside an already existing dialog of another DLL or EXE. I simply insert it as an additional dialog area inside a Tab area, possibly replacing a previous area by this new one, and the establishing a message loop.
As long as i do so, i have get access to this control.
But i mentioned above that some DLLs are using their own private dialog which is only relevant for this one and only dll.
In the mean time i found out that some other program parts need information just from the settings of such a dialog already having a message loop. Well, i could add the user defined data from this dialog to a memory register or in worst case to a config file. But knowing that these informations are quite seldomly used and only "on the fly" necessary i wont save them statically but prefer to get them directly from that dialog.
Well, it's already done so far. I can explicitely get all data from it's controls, but i did not yet manage to establish a second message loop interfering with it's original one to get the control click of it's OK button just to be able to transfer the necessary data upon user's mouse click.
I already tried everything except inserting a new process running separately from the current message loop.
Perhaps anyone of you has an idea how to SIMPLY establish an additional message loop. This loop has to be placed inside or in concurrence to the dialog's original message loop.
Ing.-Buero Doerre (IBD)
Dipl-Ing. TH Norbert Doerre
Elpenbachstr. 63 - 65
46119 Oberhausen,  Germany
Technical Hard- and Software
Computer Forensic

Patrice Terrier

#1
Norbert,

I have a few applications running several process altogether, and using a {registered private message} to perform synchronization via sendmessage/postmessage.
That works very fine by me, and on VISTA/SEVEN it opens a wealth of possibilities, to create multiple overlayered DWM applications working just like a single one (and indeed much better than one single threaded application).

...
Patrice Terrier
GDImage (advanced graphic addon)
http://www.zapsolution.com

Norbert Doerre

Patrice,

yes, i think we both are working the right way. The only difference may be that i'm not at all interested in programming Windows.
It made me too much headache in the past with it's 'unconventional' structure changes and still steals my time for important work.
Sounds very interesting what you are planning with w7, and that's just what i ever whished to happen, but now, i think it is something for the next generation.
My program runs already with w7 32 bit, but i'm not willing to publish a version for 64 bit.
I have still to write one of those nasty win installers for w7.
But currently, i'm convinced when at least two independent programmers have the same idea for the same problem to be solved, it's the right way.
Thank you so far for your lines you wrote back. ::)
Ing.-Buero Doerre (IBD)
Dipl-Ing. TH Norbert Doerre
Elpenbachstr. 63 - 65
46119 Oberhausen,  Germany
Technical Hard- and Software
Computer Forensic