|
ur reply to the poster is very interesting.
if GetParent() gets the dialog, what does m_hWnd of the new class stand for?
thx
includeh10
|
|
|
|
|
i don't know. that's just code i've always used without even looking at it. it works fine.
-c
To explain Donald Knuth's relevance to computing is like explaining Paul's relevance to the Catholic Church. He isn't God, he isn't the Son of God, but he was sent by God to explain God to the masses. /. #3848917
|
|
|
|
|
Hello,
I have a research program that runs in an endless loop. However, during this time, I would like the user to be able to stop the loop with, say, a press of a toolbar button (currently, the loop runs but doesn't respond to any other UI interaction). I saw material on 'threads' but it looked like that was specific to NT (I'm on ME).
How do I do this and where should I go for more information?
Thanks!
JennyP
|
|
|
|
|
"threads" is the right answer, and you can use them on any version of Windows.
http://www.codeproject.com/threads/[^]
-c
To explain Donald Knuth's relevance to computing is like explaining Paul's relevance to the Catholic Church. He isn't God, he isn't the Son of God, but he was sent by God to explain God to the masses. /. #3848917
|
|
|
|
|
Chris is right.
But you can also use poor man's threading by pumping the message queue, if your endless loop can be broken up into smaller tasks that are repeatedly executed. Here's how to pump the message queue.
while (moreWorkToDo()) {
doSomeWork();
pumpMessageQueue();
if (cancelled()) {
break;
}
}
void pumpMessageQueue()
{
MSG msg;
while (::PeekMessage (&msg, NULL, 0, 0, PM_NOREMOVE)) {
AfxGetThread()->PumpMessage();
}
}
Regardless of which method you select, remember to ensure that the user is prevented from executing invalid GUI operations (eg: exiting the app) during processing. Usually, the only operations permitted during processing are (1) updating progress and (2) checking if the user chose to interrupt the process.
/ravi
Let's put "civil" back into "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Since my program is really all about this loop, this solution works perfectly!! Thanks!
JennyP
|
|
|
|
|
Considering Ravi suggestion, you may also disable the parent window of your progress dialog (just reenable it when you are done) if you want to prevent user to close it or anything else.
As my daughter would say, "... Whatever!"
|
|
|
|
|
Actually that's only necessary if the progress dialog is modeless.
/ravi
Let's put "civil" back into "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Yes, of course!
As my daughter would say, "... Whatever!"
|
|
|
|
|
May be somebody know program, which autocomplete source
for exmaple
for() ctrl+f3(for example) -> for(;;)
{
}
if ctrl+f3(for example) -> if ()
{
}
else
{
}
or how make VC.NET for this;
Delphi it may this
|
|
|
|
|
I need to store, in the system registry,
the setting parameters of my application.
If I use the SetRegistryKey, my parameters
are stored in a specific folder placed in
HKEY_CURRENT_USER -> Software.
How can I store my parameters in
HKEY_LOCAL_MACHINE -> SOFTWARE in order to
be available for all users ???
Thanks a lot
|
|
|
|
|
You'll have to go beyond MFC support for registry. Use RegOpenKeyEx with HKEY_LOCAL_MACHINE as 1st argument, then RegsetValueEx and RegCloseKey.
There should be some classes wrapping Win32 API right here on CodeProject.
Tomasz Sowinski -- http://www.shooltz.com
- It's for protection - Protection from what? Zee Germans?
|
|
|
|
|
can an exe file write data to itself while running?
i mean, sometimes, an exe file writes data to register or file for many reasons (setting, recording etc.), but i feel in case it is neccessary to write data to itself (i.e. if copy the exe file, setting is copied also because the setting is inside the exe file).
do u think it is possible?
thx
includeh10
|
|
|
|
|
Yes. Study the PE file format for Win32 to make sure you write you data in an acceptable place. That’s the format EXEs are stored in.
Jeremy Falcon
Imputek
<nobr>"Life is too precious - don't waste it." - Norm Almond
|
|
|
|
|
... but he's going to write to .exe while .exe is running. This means PE file is mapped to memory, probably in read-only mode.
Tomasz Sowinski -- http://www.shooltz.com
- It's for protection - Protection from what? Zee Germans?
|
|
|
|
|
True, but he talked about copying the EXE. I just figured he'd do that and directly write to the sucker and bring it back over to the original location later on?
BTW, I'm still using your screen saver.
Jeremy Falcon
Imputek
<nobr>"Life is too precious - don't waste it." - Norm Almond
|
|
|
|
|
Jeremy Falcon wrote:
True, but he talked about copying the EXE.
Oops - it's too hot here; my monitor looses focus obviously
Jeremy Falcon wrote:
BTW, I'm still using your screen saver
Thanks. Watch for upgrade in September or, more likely, October.
Tomasz Sowinski -- http://www.shooltz.com
- It's for protection - Protection from what? Zee Germans?
|
|
|
|
|
Tomasz Sowinski wrote:
Oops - it's too hot here; my monitor looses focus obviously
Of course, I just reread what he said and now I see it as just retaining the value after the EXE has been copied - like to another computer for instance. Perception can be interesting. I'll blame my mouse for that.
Tomasz Sowinski wrote:
Thanks. Watch for upgrade in September or, more likely, October.
Spiffy!
Jeremy Falcon
Imputek
<nobr>"Life is too precious - don't waste it." - Norm Almond
|
|
|
|
|
no, exe is running, copy is something later
the exe writes date to itself, so it must be in running
includeh10
|
|
|
|
|
You can do something close. Store your piece of data in a companion DLL. Link this DLL dynamically with LoadLibrary and FreeLibrary . When you want to modify the internal data, make sure the DLL is not loaded, open it as a regular file in read/write mode, change it and close it again.
Possibly the best way to change the data without getting into PE format details is to signal the block to be changed with some beacon like this:
static char data[]=":::BEGINMARKER::: ";
so that you can search for the beacon and just overwrite what follows (being careful not to exceed the maximum space reserved in advance). You can save the searching phase if you already found out where the storing space begins (e.g. by examining the DLL with a binary editor).
This approach involves a fair amount of work, but I think it should work.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Possibly the best (and most easy ) way to store data in an .exe without going into format details is to store them as custom ressource inside the ressouce fork. Then you can update and retrieve them use simple API functions.
However, the API to store the ressource (UpdateResource()) is only available on NT and above, so if you have to support ugly versions of Windows this approach would not work
--
Daniel Lohmann
http://www.losoft.de
(Hey, this page is worth looking! You can find some free and handy NT tools there )
|
|
|
|
|
Hi Daniel
Possibly the best (and most easy ) way to store data in an .exe without going into format details is to store them as custom ressource inside the ressouce fork.
I don't really think so. Updating string resources is a pain in the ass because a) those strings are always stored in Unicode b) they are bundled into messy entry blocks (several strings per block) and the API does not give direct access to the strings themselves, only the blocks.
However, the API to store the ressource (UpdateResource()) is only available on NT and above, so if you have to support ugly versions of Windows this approach would not work.
If you are interested, Erik Kallen wrote a superb clone of this API for 9x systems that you can have a look at in his article Updating Resources on Win9x.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
i downloaded the zip and will try soon.
thx
includeh10
|
|
|
|
|
Hello Joaquín
Aehm, did I talk about string resources?
I would store the data as uninterpreted custom resource. You can store any binary data this way.
Joaquín M López Muñoz wrote:
If you are interested, Erik Kallen wrote a superb clone of this API for 9x systems that you can have a look at in his article Updating Resources on Win9x.
That's really good news for all those poor folks who have to support bulshit OS versions
(And obviously the code would throw light on how to deal with PE and resource formats! Very interesting!)
--
Daniel Lohmann
http://www.losoft.de
(Hey, this page is worth looking! You can find some free and handy NT tools there )
|
|
|
|
|
I would store the data as uninterpreted custom resource. You can store any binary data this way.
Didn't think of it at first. Yes, this avoids the strings hassle.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|