|
Thanks for responce. This DoEvent call itself is from thread
since the UI is almost frized, I am using waitableTimmer from a thread to update the progress bar, it is fine,but if I min & Maximize; the window, progress bar is ok but UI(App main window , Dlg box) in not refreshed/redrawn untill the currentl lengthy operation is done. Can not put the length process in thread. Any wise advice pls
|
|
|
|
|
ptr_Electron wrote: Can not put the length process in thread.
Why is this not possible can you explain??
Regards,
Sandip.
|
|
|
|
|
No no, Techinical possible, but not as per the req, if I need to do that much of the code required changes.
|
|
|
|
|
You have a primary thread that handles the UI and keeps it responsive. You have a secondary thread that does some work. During that work in the secondary thread, simply post a message to the primary thread telling it of the progress. This way, both threads can do what they're designed to do without worrying about the other.
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
Why the Sleep nonsense? Something like this looks more civilised:
void DoEvents()
{
MSG m;
while (::PeekMessage(&m, NULL, 0, 0, PM_REMOVE))
{
::TranslateMessage(&m);
::DispatchMessage(&m);
}
}
Steve
|
|
|
|
|
Did that but even then no luck
|
|
|
|
|
I didn't say it would fix your problem; I was just pointing that the Sleep is extremely poor programming and is not needed.
Steve
|
|
|
|
|
ptr_Electron wrote: Sleep(100); // Try to minimize CPU usage
Remove this. It serves no purpose.
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
Yes I removed sleep. I am using waitableTimmer to keep the UI active, during a very length call. Progress bar is working fine, but UI is Frised pls suggest me some good idea for this,
HANDLE timer = CreateWaitableTimer(0,false,0);
LARGE_INTEGER li;
const int unitsPerSecond=10*1000*1000;
li.QuadPart=-(2*unitsPerSecond);
SetWaitableTimer(timer,&li,350,0,0,false);
_beginthreadex(0,0,TF,(void*) timer,0,0);
unsigned __stdcall TF(void* arg)
{
HANDLE timer=(HANDLE) arg;
while (1)
{
if(iStoped==0)
return 0;
WaitForSingleObject(timer,INFINITE);
prgBar->StepIt();
DoEvents();
}
_endthread();
return 0;
}
void DoEvents()
{
MSG oMSG;
while(::PeekMessage(&oMSG, NULL, 0, 0, PM_NOREMOVE))
{
::TranslateMessage(&oMSG);
::DispatchMessage(&oMSG);
}
}
|
|
|
|
|
By using a secondary thread to do the work, your DoEvents() function is not needed. You have to stop thinking of 16-bit Windows.
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
Hi,
Just needed a little guidance. Am creating a drive imaging utility mostly to understand the working. Can anyone guide me to a tutorial/example to make images of HDD on windows/linux using C/C++. Just the right direction will suffice. I tried googling it but all i get are the softwares to create the images not the actually approach to the problems.
thanks.
|
|
|
|
|
In linux, it is easy, just open the proper device. A raw harddisk is represented by say /dev/hda where as the partitions are represented by /dev/hda1, /dev/hda2, etc. Just open the file with fopen and use fread to read the data.
In WinNT (to include subsequent versions such as XP, etc) you can actually open device files the same way, but it is a lot messier. The NT kernel creates pseudo files like linux, but they are not as neatly grouped. They look like \\.\Volume{46b98f60-4a74-11dc-9364-806d6172696f}\ but have simpler aliases like \\?\Device\HarddiskVolume2
There is a open source program called rawwrite dd for windows that does just what you require and maybe you can glean some information from the authors homepage or from the source code:
http://uranus.it.swin.edu.au/~jn/linux/rawwrite-old.htm[^]
|
|
|
|
|
Thanks ...
|
|
|
|
|
Hi!
i want an article about .net exe files.
i want inject my code in this files (.net). how do i do?
i can inject my code in win32 PE files, but for .net exe file ???
please help me
Zo.Naderi-Iran
|
|
|
|
|
A .net exe is also a PE file.
Steve
|
|
|
|
|
i inject my code to .net exe file similar PE exe file. but it (.net exe file) is corrupted!!!!
Zo.Naderi-Iran
|
|
|
|
|
Hello everyone,
In COM Marshalling, if we marshall an interface from one apartment to another, then in the foreign apartment (where the interface pointer is marshalled to) the interface pointer points to the proxy object other than the original object.
My questions is, proxy object is only binding to the interface from Wnidows registry, how does the proxy object binds to the original coclass object (i.e. when we call methods in the proxy object, it is able to call the original coclass object)?
thanks in advance,
George
|
|
|
|
|
I'm not sure what you mean by "binds". If you mean how does it communicate to the real COM object then the answer is it depends:
- If the object is in a different process then PRC is used.
- If the COM object is apartment threaded and in the same process then windows messages are used.
Steve
|
|
|
|
|
Sorry for my bad English, Steve!
My question is, how could the proxy object finds which is the original coclass obejct to communicate with? Is there hard coded CLSID for the original coclass object in proxy object?
regards,
George
|
|
|
|
|
Proxy's and stubs are for interface s, not coclass es. If you look in the registry under the HKEY_CLASSES_ROOT\Interface\{Your IID} key you'll see a ProxyStubClsid32 key. In some cases you may use the CoRegisterPSClsid[^] method instead.
Steve
|
|
|
|
|
Sorry for my bad English expression, I understand proxy is for interface, not for original coclass. Suppose in the following scenario,
1. in apartment A, there is a coclass object called CA, which implements interface IA;
2. we marshall interface IA from apartment A to apartment B, and the marshalled interface is IB;
3. IB points to proxy object, say PB;
4. when we are in apartment B, and call method through IB, and PB is called and PB will communicate with original coclass object CA through interface IA.
My question is, in step 4, how could proxy object PB know which coclass object (CA in this case) it should communicate with?
regards,
George
|
|
|
|
|
It's not a matter of which coclass but rather which interface . As to how does it knows which interface it's simple, it’s the one you marshalled.
Steve
|
|
|
|
|
Thanks Steve,
I think you mean when we call from the marshalled interface, it could find the related proxy object, correct? But the actual function is executed in the original object and returned back from proxy object to client, my question is how could proxy object know which is the original coclass object which it will send call parameters to and retrive return result from?
regards,
George
|
|
|
|
|
George_George wrote: my question is how could proxy object know which is the original coclass object which it will send call parameters to and retrive return result from?
The proxy knows nothing about coclass es, all it knows about is interface es. When you marshal the interface you obviously supply a pointer to the interface to be marshalled, and you also supply its IID : this is all the information COM needs from you to hook things up.
Steve
|
|
|
|
|
Thanks Steve,
The IID is both the interface which proxy implements and also the original coclass implements.
But if we only provides the IID, how could proxy knows which original coclass implements the IID and call the original coclass?
regards,
George
|
|
|
|