|
Hi, I want to know how this OpenPrinter() API works.
It is returning ERROR_INVALID_PRINTER_NAME if i use this api.
On what basis it is able to tell whether printer name is valid or invalid?
Which registry key it is comparing with?
Thanks in advance.
Regards
msr
|
|
|
|
|
See here[^] for specific details of the name format. You may want to check what parameters you are using in your call.
I must get a clever new signature for 2011.
|
|
|
|
|
Hi,
I need to set the focus to the window that had the focus before my dialog was first selected. To be more precise: as soon as the user clicks a button in my dialog, I want to set the focus to the window that had the focus before the user clicked in my dialog. I also want to be able to realize if that window has been closed in the meantime. What is the best way to achieve that?
Thanks alot for any suggestions.
|
|
|
|
|
hi
store the handle to window for the previous window in memory, recall this hwnd to set focus whenever you want.
"I also want to be able to realize if that window has been closed"
use IsWindowVisible option for this.
Regards,
A. Gopinath.
|
|
|
|
|
Hi, adding to Gopinath's point you can use FindWindow API also. Refer it in msdn.
Regards
msr
|
|
|
|
|
Erik wrote: I want to set the focus to the window that had the focus
You can handle the WM_SETFOCUS message. One of its parameters is the handle to the window that has lost the keyboard focus.
Erik wrote: I also want to be able to realize if that window has been closed
You can use the IsWindow() function to determine if the window has been closed (i.e., destroyed).
|
|
|
|
|
Hans Dietrich wrote: You can use the IsWindow() function to determine if the window has been closed (i.e., destroyed).
Although this works in the most of the case, it is not "safe": when a window is destroyed its handle becomes invalid and the is ID (the handle value) can be reused by the system for another subsequently created window.
If you don't look at all that while happening, IsWindow may return TRUE, but the window may not be the one you intended.
(I mean: "my name (handle) is the same of my grandfather, I was born after his death, and I live in what it was his house. But I'm not him"! But if you send a letter to him, I'll read it as mine and, hopefully, I can understand the misleading only from the context".)
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
Hi,
I am looking for code sample which will explain how to actually pass handles from parent to child process.
I konw:
A child process can inherit handles from its parent process. An inherited handle is valid only in the context of the child process. To enable a child process to inherit open handles from its parent process, use the following steps.
1.Create the handle with the bInheritHandle member of the SECURITY_ATTRIBUTES structure set to TRUE.
2.Create the child process using the CreateProcess function, with the bInheritHandles parameter set to TRUE.
Can someone please share some code sample which would help me understand how to actually use the passed handle in child process.
Thanks in advance!!!
modified on Monday, March 21, 2011 7:13 AM
|
|
|
|
|
Look at the documentation for SetHandleInformation and DuplicateHandle.
|
|
|
|
|
Hi,
I know how it is passed. I want to know how to retrieve and use them in child process. An example will help
Sudhan
|
|
|
|
|
A simple MSDN search yielded this[^].
I must get a clever new signature for 2011.
|
|
|
|
|
I had seen this link. I was wondering how to use it for other type of handles (like mutex, sempahore etc, though they can be retrieved through api like OpenMutex) in child process.
|
|
|
|
|
This issue is specifically about File Handles as far as I know; the other types do not fall into the same category.
I must get a clever new signature for 2011.
|
|
|
|
|
You described how to make the handle available in the child process, but you still need to tell the child the numerical value of the HANDLE. A common way of doing this is to pass the value as a command line parameter.
--Mike--
Dunder-Mifflin, this is Pam.
|
|
|
|
|
Hi Mike,
This is what I was looking for. Handles are copied in the process table of the child process if the inherit flag is set to true but how would the child process know which handle is pointing to which kernel object and which to use.
This link [^] explains the concept:
"To use a handle, the child process must retrieve the handle value and "know" the object to which it refers. Usually, the parent process communicates this information to the child process through its command line, environment block, or some form of interprocess communication."
I was looking for an sample code showing the above step(highlighted in bold).
|
|
|
|
|
When you create an object (like a mutex) you can specify a "name".
(see CreateMutex[^]).
In the child process you can retrieve another handle to that same object with OpenMutex[^], or whatever similar and coherent with the type of object) by giving it that name (that is supposed to be unique at least between all your entangled processes).
Note that the returned value may be different, due to the fact the the handle value is an "index of a table of indexes" that is different in the various processes.
The documentation talks improperly of inheritance of handles. What are inherited are the objects the handle refers to.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
I think I'm front with a weird problem at combo box control :
If drop down list of combo box is down , and I delete all strings from combo box and call ShowDropDown(FALSE); I have assert error on strcore at 519 line .
In fact , it's mistake to call ShowDropDown(FALSE); when combo box is empty ?
|
|
|
|
|
Don't know what might cause that error but try "undropping" the list and then delete the strings? Or there's a particular reason why you try to delete first and then remove the list?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> //TODO: Implement signature here<
|
|
|
|
|
Yes , you are right , I thing that's the way to solve this problem ... weird behaviour . Thank you !
|
|
|
|
|
Yourwelcome.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> //TODO: Implement signature here<
|
|
|
|
|
|
Interesting article, thanks for the link. 
After reading it, I would say you can apply the same principle to STL by using the registry entry “std\:\:.*=nostepinto” instead of “ATL\:\:.*=nostepinto”. I haven't tried though. In any case, before trying this I'd create a restore point or whatever else you usually do to undo an unlucky change. It is an undocumented feature after all, and even if it weren't, manually editing the registry isn't for the weak of heart. 
|
|
|
|
|
Hey, that actually works! Thanks
|
|
|
|
|
Every day you learn something new, is a good day. Thank you!
|
|
|
|
|
Excellent, thanks!
"Real men drive manual transmission" - Rajesh.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
