|
I expected Execl to load the file before it is deleted. It works with CSV-files.
But XML-files seem to take more time to be opened.
I solved the problem this way, that I use OnClose() to search and delete all temp-files, that my appl has created. It works.
Juergen
|
|
|
|
|
e-DJ wrote: I expected Execl to load the file before it is deleted.
Not sure why you expected that. Unless told to do otherwise, Windows is asynchronous in nature. You have to explicitly provide synchronization constructs.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
All,
Can we post/send a message [ using PostMessage()/SendMessage() API ]from ATL COM DLL to the calling application window if we wanted to update the GUI periodically ?
It seems it is consuming lot of memory when I post or send message from DLL to the applicaton GUI window.
Thanks,
AKS
|
|
|
|
|
AKSIVAKUMAR wrote: It seems it is consuming lot of memory when I post or send message from DLL to the applicaton GUI window.
How are you verifying this?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
David,
I am using a tool to verify the memory leak. Moreover, If i comment that particular line and do run the application again, it consumes less memory.
Regards,
AKS
|
|
|
|
|
AKSIVAKUMAR wrote: If i comment that particular line and do run the application again, it consumes less memory.
What does the recipient of those messages do with them?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
just display the data on the GUI that comes from the DLL.
|
|
|
|
|
What type of data? How much? Is painting involved, or is it just text?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I think the problem isn't the message you are sending but your painting rutines that maybe are not freeing the allocated resources.
|
|
|
|
|
Kharfax,
To inform you that I don't have any painting routine inside my application for this purpose. Just I am posting a message to application handle(m_hWnd)to display them on the GUI.
Please let me know if you have any suggestions ?
Regards,
AKS
|
|
|
|
|
i need to send a file thro network using by Bus master NIC
for tht i need to initiate the dma trasfer of the NIC device
how to do it????
wht shld i do to make the file compatible for DMA transfer??
|
|
|
|
|
You can't access any hardware directly in WinNT+.
You will have to write a Windows driver (or find a usable driver, written by someone else) in order to send the file to the NIC. (A driver has the permissions needed to access the hardware).
So get Windows DDK and start coding.
Alcohol. The cause of, and the solution to, all of life's problems - Homer Simpson
|
|
|
|
|
Hi,
Suppose to use PostMesage to post some kinds of message to the thread's message queue.The question is: If WM_CLOSE message already was queued, before WM_CLOSE is processed, can we continue to append other messages into the queue after the WM_CLOSE by using PostMessage?
|
|
|
|
|
brucerain wrote: can we continue to append other messages into the queue after the WM_CLOSE by using PostMessage?
You can post as many messages you want even if there is a pending WM_CLOSE message in the queue. Whether the messages that follows the WM_CLOSE message gets handled or not depends on how the WM_CLOSE message is handled. Normally DefWindowProc() will call DestroyWindow() when a WM_CLOSE message is received. DestroyWindow() then flushes the message queue among other things.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote "High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
The WM_CLOSE will probably only affect the window to which it was targeted. If you are truly posting messages to the thread's message queue, then they are processed independant of a window being opened or not. Messages posted to a thread queue will have a HWND parameter of 0.
|
|
|
|
|
Sorry for not expressing it clearly.The exact meaning is posting message to a window, What I want to know is that if other messages can be post to a window after WM_CLOSE message was already queued, there may be memory leak when message parameters wParam or lParam is really a pointer and must be deleted in the message handling function.
The background of this question is:there is an object created in the heap and there are more than one window need to process this object.We post this object as
a pointer in the parameter wParam and decrease the object reference after processing it.If message was post to the window's message queue but not processed by the window, then reference counter will never be decreased and the object will
never be deleted.So memory leak happens!
Anybody knows how to process this kind of problem?
|
|
|
|
|
You'll need to handle the WM_DESTROY [^] notification, which is sent to your window when it is destroyed. In that handler, use PeekMessage [^] to look for occurrences of your user-defined message. Using the returned WPARAM and LPARAM values for the message(s), free the memory. As a final bit of cleanup, set the last parameter to PeekMessage to PM_REMOVE to remove the messages from the queue.
Software Zen: delete this;
|
|
|
|
|
All,
I have created a MDI application. In that, I have created many child frames and able to display/show during the application startup.
But, whenever a child window is created, the system automatically appends a new menu item to the window menu. The text of the menu item is the same as the text on the menu bar of the new child window. By clicking the menu item, the user can activate the corresponding child window. When a child window is destroyed, the system automatically removes the corresponding menu item from the window menu.
It seems that, the system can add up to ten menu items to the window menu. When the tenth child window is created, the system adds the More Windows item to the window menu. Clicking this item displays the Select Window dialog box. The dialog box contains a list box with the titles of all MDI child windows currently available. The user can activate a child window by clicking its title in the list box.
How to avoid this and I don't want the system or the framework automatically appends a new menu item to the window menu. I want to restrict this urgently.
Is there any way to restrict this ?
Any suggestions ?
Regards,
Siva
|
|
|
|
|
any suggestions or tricks from anybody from the forum ?
|
|
|
|
|
Hi,
I implemented an XP theme into my application which was orignially written in visual C++ 6.0. I followed the steps recommended here
http://www.codeproject.com/w2k/xptheme.asp
What I have found is that the combo boxes in read only form have not turned out as they should. They should be greyed out with the drop down button on the right of the combo box. But instead they look like edit boxes that are greyed out. Anyone know how to get the button back to the right of the combo box (so that it looks like a combo box and not an edit box)?
Many thanks !
|
|
|
|
|
why don't you directly ask in the article message bord at the bottom of the article ?
the author will certainly be able to answer better than anyone
|
|
|
|
|
Actually, it's probably better to ask here since this question doesn't really address the article as much as it addresses standard windows control behavior.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Options:
1) The button is a window, so if you can get a hwnd to that button, you should be able to disable it. Create a basic dialog-based app with a single combo box control in it, and use Spy++ to see if you can get the necessary info about the various parts of the control.
2) You may have to set the control to be owner-drawn so you can handle the disabled appearnce manually.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
And googling found this article right here on CodeProject:
http://www.codeproject.com/cs/miscctrl/disabledcombodisplay.asp[^]
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|