|
Hello,
Your control handler never leaves execution. This means that no message gets processed after you press button1.
You can solve this problem by posting a message to your own window after the call to UpdateData().
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
In OnButton1, create a timer (i.e. SetTimer) with a delay of 1 millisecond. Let OnButton1 return. Inside the OnTimer method, update the edit control. Do not kill the timer. Inside of OnButton2, add a call to KillTimer to stop the timer.
This is very simple method of doing what you ask without having to create new threads or anything complicated. Since timer events are very low priority, the edit box will be allowed to update and the UI will continue to pump messages.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
If you kill the timer in the OnTimer method then start it again after the edit control is updated. This guarantees a 1msec delay between actions, otherwise you could get a queue of timer events in the time all the processing takes.
The tigress is here 
|
|
|
|
|
thank you.
I used the timer idea and it actually worked 
|
|
|
|
|
Trollslayer wrote:
otherwise you could get a queue of timer events
AFAIK WM_TIMER, like WM_PAINT, is a low priority and does not queue. A WM_TIMER message is only posted when the message queue is empty.
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" - mYkel - 21 Jun '04
"There's not enough blatant self-congratulatory backslapping in the world today..." - HumblePie - 21 Jun '05
Within you lies the power for good - Use it!
|
|
|
|
|
PJ Arends wrote:
WM_TIMER, like WM_PAINT, is a low priority and does not queue
This is correct. This is handled by the kernel and there will never be any WM_PAINT or WM_TIMER messages in the thread's message queue.
Regarding timers it's ridiculous even thinking that such a timer will have a period time of 1ms. Windows is not a real-time OS.
What will happen is that you will not get multiple WM_TIMER messages in the queue, BUT the WM_TIMER handler won't get called in the rate you expected.
You can simply verify this by the use of ::QueryPerformanceCounter and logging the rate that the handler is actually called.
Joe Newcomer wrote an excellent article about this and can be found at
http://www.flounder.com/time.htm[^]
--
Roger
|
|
|
|
|
thank you.
I used the timer idea and it actually worked
|
|
|
|
|
Hi all
I have a toolbar IDR_MAINFRAME with 8 Icons . During runtime, I want one of the buttons to be disabled or grayed .
I can see the usage of ON_UPDATE_COMMAND_UI here in mainfrm.cpp
ON_COMMAND(ID_FILE_PRINT, OnIDFilePrint)
ON_UPDATE_COMMAND_UI(ID_FILE_PRINT, OnUpdateFilePrint)
here OnIDFilePrint() is called when I click on the "Print" toolbar button .
But as I am new to usage of pCmdUI etc , I dont know how to disable the 6th button - print button in this toolbar .....
Anyone to help me ...?
I need to disable this toolbar button from outside the mainfrm.cpp ...
Any help pls ....
redindian
|
|
|
|
|
dharani wrote:
ON_UPDATE_COMMAND_UI(ID_FILE_PRINT, OnUpdateFilePrint)
For achieving same you have to have handller for each of toolbar button... and implement the coding for individual
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
Hi alok
I did not get it ...
In fact in my code (9000 files) , I can see this print button disabled /enabled during runtime based on some inputs ...
But I am not able to find out the particular code which send a message to disable the print icon/button ....I have been searching for something stright like EnableWindow(0) ...and found the mechanism is very different ...
Any clues of diabling a toolbar button which uses this pCmdUI interface ?
redindian
|
|
|
|
|
dharani wrote:
Any clues of diabling a toolbar button which uses this pCmdUI interface ?
Could you show me current coding of OnUpdateFilePrint HANDLLER for On_update_Command_UI ..
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
I think any button can be disabled by getting a pointer to it and calling EnableWindow()
SkyWalker
|
|
|
|
|
dharani wrote:
But as I am new to usage of pCmdUI etc , I dont know how to disable the 6th button - print button in this toolbar .....
In the on_update handler for ID_FILE_PRINT, use:
void OnUpdateFilePrint( CCmdUI *pCmdUI )
{
pCmdUI->Enable(FALSE);
}
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
david crow has given u the correct answer...
tiru
|
|
|
|
|
The USB flash disk have no CHS parameters (the system use virtual parameters),I only need to get teh total sectors for physical drive. The MBR and BOOT may be failure. so your function is invalid. ,how to do it? Thanks.
|
|
|
|
|
Hi,
Could you please elaborate the question?
Are you looking for the Sector information of the Physical drives i.e Hard disk or USB disk??
|
|
|
|
|
I want to get the disk size for every physical disk. The CHS parameter is true for harddisk,but wrong for USB flash disk. Becase the system assume that's X*255*63,the total sectors are also wrong. I dont know what function can I use.
|
|
|
|
|
Hi As per my knowledge, You can open any disk (using CreateFile(DriveName,....)and after reading the first sector of the disk you will get Boot record of the same from there I feel you can get the size of the disk
Otherwise harddisk has Master boot table from where you can get the partitions and their sizes.If you want to open a physical drive you can open it using the CreateFile("\\\\.\\PHYSICALDRIVE0",....) for the harddisk.and after reading the MBT you can get the drive information .If you want to use the WINDOWS api then you can use GetDiskFreeSpace() API and pass NULL as a root directory it will return you the TOTAL number of clusters,multiply it with the Sectores per cluster and bytes per sector.You will get the disk size.
|
|
|
|
|
Hi all,
I am writing a simple application in VS.NET 2003 which uses my own dll (vz.dll). The dll is for my C++ library which the application uses. See the scenario below:
app (my own application) --> uses vz.dll (a C++ API exporting its class functions, my own classes). I am building the DLL with /MTd flag enabled rather than using flag /MDd. Also I am calling the constructor within the DLL with new.
Debugging the application, when I exit the application I do deletion of my data(calling delete on an instance created using new) I get the following exception with the stack trace
Unhandled exception at 0x7c822583 in app.exe: User breakpoint
ntdll.dll!7c87512a()
ntdll.dll!7c8754d1()
ntdll.dll!7c8409a8()
kernel32.dll!77e6b28e()
kernel32.dll!77e755b9()
vzclient.dll!_CrtIsValidHeapPointer(const void * pUserData=0x01da27a0)
Line 1807 C
vzclient.dll!_free_dbg_lk(void * pUserData=0x01da27a0, int nBlockUse=1)
Line 1132 + 0x9 C
vzclient.dll!_free_dbg(void * pUserData=0x01da27a0, int nBlockUse=1)
Line 1070 + 0xd C
vzclient.dll!operator delete(void * pUserData=0x01da27a0) Line 54 +
0x10 C++
vzclient.dll!vzTMRenderAction::`scalar deleting destructor'() +
0x3c C++
app.exe!CleanVolumizer() Line 438 + 0x34 C++
I commented out the deletion of the data which was causing this. After which I am still getting the same exception
Unhandled exception at 0x7c822583 in app.exe: User breakpoint.
But now the location of exeption has shifted to dbgheap.c when the _CrtIsValidHeapPointer returns.
Though it seems to me a heap corruption but I have no clue why it is happening and where. I also tried using gflags utility but not of much use.
Please help me, I am stuck.
Any help/ suggestion is welcome.
Thanks in advance,
Divick
|
|
|
|
|
Could it be that you are using 'new' in a release-built dll and 'delete' in a debug-built app?
--
Roger
|
|
|
|
|
Hi thanks for the reply. Well I have rechecked that, it is not the case. I am using same version for both (debug and release), but yes there is another third party dll that I am using for both the release and debug versions.
Another thing that I wanted to mention was that the problem occurs only with the DEBUG versions of the application and dll but not with the RELEASE versions.
Since to me what it feels like a heap corruption issue, I seriously doubt that if the error is not showing up now, then it won't show up later.
Any ideas about this.
Thanks a lot for your reply,
Divick
|
|
|
|
|
Well, there's nothing to do but get your fingers dirty and do some serious debugging on the pointer that is being freed.
There's no way of telling you anything more about what could be wrong, you're on your own here.
I suggest you TRACE the value of the pointer when it's getting initalized ('new'), TRACE it again when the application is running and TRACE it a third time when it's about to be freed ('delete').
The pointers written to your debug window should be the same, but they most likely won't be.
This is to find out whether the pointer gets overwritten, or altered, in the startup sequence or when closing the application in order to isolate the failure.
--
Roger
|
|
|
|
|
Are you using static or dynamic CRTL? If you are using static, then you might be running into the problem where you are allocating memory in the DLL and then trying to free it in the EXE. Or visa-versa. With a static CRTL, you will have two heaps in existance, the one in your DLL and the one in your EXE. You can't allocate memory in one and then free it in another.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Hi,
thanks for the reply. I think I am using the static CRTL(rather MSVCRT.dll, the C++ Run time library specified using the /MT flag rather than the /MD thread). But I am deleting the data within the application which is where I create it.
Further debugging into the code I have found that checking the validity of the pointer with assert and _CrtValidHeapPointer in the application does not create any problem but checking that within the DLL causes an exception. See the code snippet below;
//---------application code
MyOwnClass * myOwnPtr = new MyOwnClass();
//new and deletion is being done in the application only
_ASSERTE(_CrtIsValidHeapPointer(myOwnptr));
_ASSERTE(_CrtIsValidPointer(myOwnptr,sizeof(myOwnptr),true));
delete myOwnptr;
//-----------------DLL code
MyOwnClass()::~MyOwnClass()
{
_ASSERTE(_CrtCheckMemory());
//////////////////////////////////
//This causes a pop up box with the following message unhandled exception at 0x7c822583 in app.exe: //User breakpoint. and takes the debugger to dbgheap.c file
//////////////////////////////////
_ASSERTE(_CrtIsValidHeapPointer(this));
}
Even if I comment the code for assertion of this pointer in the above destructor then again when the destructor returns the same exception is thrown in dbgheap.c
Does it clarify my question a bit more?
Thanks for your help,
Divick
|
|
|
|
|
One more update to this one. Changing my application as well as DLLs to compile as /MDd (i.e. as multithreaded DLL , yeah the application as well) eliminated the error completely.
Though I understand that with /MT the C run time is linked statically and with /MD the CRT is linked dynamically (correct me if I am wrong) but I am really wondering why at all should it create problem with memory allocations at all? 
Second I always thought that /MD is only for DLLs while it is also applicable to applications as well. Should one always be using the flag /MD for building all kind of applications?
Any ideas / suggestions are welcome.
Thanks,
Divick
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
