|
Are you going to implement a tree? There's no standard tree container (map and set use trees, but this is an implementation detail). I think the easiest way is to add a vector<CMyClass *> to CMyClass - this vector will hold pointers to children objects. You can also add a parent pointer, which will be NULL in the root object.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
I have an application on iPAQ that needs to communicate to a device through the comm port. I use GetCommState(...) to get the DCB values and then modify its baudrate, bytesize, stopbit and parity values. Later when i try to apply these changes using SetCommState(...), it just hangs there.
When i switch off the device, it returns with no error. Does anyone know what is causing this problem?? Thanks. 
Wee Giap
|
|
|
|
|
Hi
As far as I know it is possible for other applications to
get a handle of the window from my application (e.g.: FindWindow), and then it is possible for this application to write into my window. Does anyone know a method to prevent this?
Thanks in advance
|
|
|
|
|
It's not possible to hide a HWND. You may try to make FindWindow harder to use - for example, by generating class name randomly each time your program starts, but this doesn't give you 100% protection - it's possible to iterate over all windows in the system.
BTW: What are you afraid of?
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
I'm writing a high security digital signature ActiveX control. And I thought it would be bad if another program writes into my window and then the signer thinks he signs something different then he really signs.
I try know with Win32 Hooks. I hope this helps.
|
|
|
|
|
What if another program displays its own window looking like yours? Assuming that users's machine is infected by worm or virus targeting your ActiveX, there's not much you can do.
I'd keep a checksum (or even a verbatim copy) of displayed text somewhere. Even if this program writes its own text, you'd be able to detect data corruption.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
The text is already secured through a hash value, so it can't be corrupted. But this other program is able to write into my window and the user sees something different than he signs!
This other thing, with the virus looking like my ActiveX is a problem too. I thought I can do something in correspondence with the server programm to which the signed file is sended.
Do you have any ideas?
Martin
|
|
|
|
|
Hello NitramR,
Try this idea. I haven't checked it out, but it should work. There are a few different ways of acheiving the end result.
1a) System wide hook that hooks each process. This loads your spy DLL into their process when their process starts.
1b) Use CreateRemoteThread() to inject your DLL into the running process. You'll need a thread to watch for new processes and then inject your DLL into each new process. This is more complicated than a system wide hook, but acheives the same result.
2) Your DLL will then hook the Kernel/User/GDI/whatever DLL functions that you think are appropriate. In this case you'll want to be hooking User32 functions related to finding windows.
In your hooks you'll let the function execute then examine the return value before returning. If the value indicates your window you'll overwrite the value to indicate failure.
3) Their program will search for the window and fail.
There is info on hooking technique elsewhere on this site and also in MSJ/MSDN website/magazine.
Caveats.
--------
If they know which DLL you are loading they may be able to write code to hook LoadLibrary and LoadLibraryEx and prevent the library from loading dy diverting the function call and returning a library not loaded return code. Not hard to do. If they get their hooks in before you get your hooks in, you have lost the battle.
Cheers
Stephen Kellett
--
C++/Java/Win NT/Unix variants
Memory leaks/corruptions/performance/system problems. UK based.
Problems with RSI/WRULD? Contact me for advice.
|
|
|
|
|
Ok guys
I did some research on hooks and I'm know convinced that there is know solution for this problem.
The only thing to do, in my opinion, is to warn the user and give him the responsibility to keep his computer free of viruses and stuff like that.
Thanks anyway.
|
|
|
|
|
There is a mistake in the previous message. Of course I meant: "I'm NOW convinced that there is NO solution for this problem."
SPEED KILLS
|
|
|
|
|
I created regular dll by the wizard.
I have a dialog class in it and I writed export global function so:
/********************************************************/
extern "C" __declspec(dllexport) int func()
{
AFX_MANAGE_STATE(AfxGetStaticModuleState());
MyDialog dlg;
dlg.DoModal();
return dlg.num;
}
/********************************************************/
But when I test it with client program it dont show me the dialog.
It is only return me the return value.
WHY ???
What can I do ??? PLEASE HELP !!!!
|
|
|
|
|
So are you Gil, or are you Lili?
|
|
|
|
|
Hi,
How do I get flat scrollbars in a CTreeCtrl?
For at CListCtrl it's done by using SetExtendedStyle(), but I can't find any similiar member function in CTreeCtrl.
Roar
|
|
|
|
|
I'm afraid you can't do that. There's no TVS_xxx style for setting flat scrollbars. Even if you use InitializeFlatSB, FlatSB_ShowScrollBar and FlatSB_SetScrollProp with CTreeCtrl's HWND, all you'll get will be flat scrollbar that doesn't scroll the window contents.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
??
I would really like to recursively call the OnPrint function but everytime I try, it's catastrophically not working. I am doing something wrong or is this just not possible?
Sincerely,
Danielle (an overworked graduate student)
|
|
|
|
|
Recursively calling OnPrint is rare and most likely not needed. Write your own Print() method and call it. Otherwise, study the OnPrint() method flow-you can completely replace it without any problem if it does not meet your needs.
The framework calls the OnPrint() after a lot of preparations.
Best regards,
Paul.
Paul Selormey, Bsc (Elect Eng), MSc (Mobile Communication) is currently Windows open source developer in Japan, and open for programming contract anywhere!
|
|
|
|
|
Hello,
I have an ActiveX control and it receives the WM_MOUSEWHEEL message in both VB and VC applications.
Now, I am convering the client window of the ActiveX control with a CWnd (say view). This child view receives all messages except the WM_MOUSEWHEEL messages in VC. However, in VB applications the view receives the WM_MOUSEWHEEL all right.
What is the problem here? and why the difference in VC and VB applications?
Best regards,
Paul.
Paul Selormey, Bsc (Elect Eng), MSc (Mobile Communication) is currently Windows open source developer in Japan, and open for programming contract anywhere!
|
|
|
|
|
We are creating an app using Win32 where the user is able to define the GUI through a Python console. In order to do this, I have created a dialog, which will be invisible, and am making everything else a child of this dialog, so we don't get a gazillion things on the task bar. This works fine for the console dialog, it comes up as a seperate window and comes to the foreground when I click on the invisible window's task bar button. But when I make my windows WS_CHILD and children of this dialog, they live on the dialog, instead of being windows in their own right, able to wander the desktop freely, but without a task bar button ( which is the whole point ). I can see how this behaviour is to be expected, the question is, how do I get the behaviour I want ?
Is there a way to just hide from the taskbar ? I will then have to iterate through the windows when the parent window is chosen and show them all I guess, or is there a better way ?
Christian
As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet.
Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
|
|
|
|
|
Hello Christian,
You better state the specification more clearly. What are the child makeup? dialogs? controls?
Best regards,
Paul.
Paul Selormey, Bsc (Elect Eng), MSc (Mobile Communication) is currently Windows open source developer in Japan, and open for programming contract anywhere!
|
|
|
|
|
Like I said, they are Windows, as in I register a window class and create a new window. I've found I can get these windows not to have a task bar button if I make them tool windows, but I don't want to *do* that. I want normal windows, with a normal system menu ( close/maximise/minimise ) but nothing on the taskbar. My console is a dialog, and creating dialogs works fine and dandy with WS_CHILD, but not creating a normal Window. My top parent window is a dialog, and I've made it one pixel wide and at -20, -20, on the basis that multi monitor users are unlikely to find it there, and I need to make it visible or I get the same old problem ( nothing on the taskbar ), but this window exsits solely to be a parent to all my other windows, of which I could have as many as the user decides to create at runtime through the Pyton console.
Christian
As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet.
Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
|
|
|
|
|
Okay, how about the WS_POPUP/WS_POPUPWINDOW?
Best regards,
Paul.
Paul Selormey, Bsc (Elect Eng), MSc (Mobile Communication) is currently Windows open source developer in Japan, and open for programming contract anywhere!
|
|
|
|
|
Either of those styles kills my window by losing my caption bar and/or my border. Neither of them removes the button for that window in the task bar.
I am able to create the windows, and the windows look exactly as I want them to, but the problem is that WS_EX_APPWINDOW looks right but puts a button in the task bar, WS_EX_TOOLWINDOW doesn't give me a taskbar button, but it also doesn't give me minimise/maximise buttons or a normal size caption bar.
Christian
As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet.
Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
|
|
|
|
|
Well, you might have to experiment a bit more. If all fails, the obvious solution is to do the custom caption-if it is MFC application then there are so many codes out there, if pure SDK/Win32 I have ported the Paul Dislacia's code (MSJ) for my Win32 framework I was not able to complete.
Also, if you are not in harry, I could take a look at the problem too.
Best regards,
Paul.
Paul Selormey, Bsc (Elect Eng), MSc (Mobile Communication) is currently Windows open source developer in Japan, and open for programming contract anywhere!
|
|
|
|
|
Christian,
Have had to something very similar, and so I looked up a few details that I'd forgotten. The basic info is from the MSJ November 97 "Q&A:Win32" column by Jeff Richter. I think this should do what you want, although I remember having to 'fiddle' a little to get exactly the effect I was after.
>>
Q I'm writing a wizard-like application that leads the user through some setup tasks. Since I spawn this application from my main application, I don't want the system's taskbar to show a button for this window. I've performed many experiments and I can't seem to figure out what rules the taskbar uses to determine whether it should show a button for a window. What are the rules?
A The rules the taskbar uses to decide whether a button should be shown for a window are really quite simple, but are not well documented. When you create a window, the taskbar examines the window's extended style to see if either the WS_EX_APPWINDOW (defined as 0x00040000) or WS_EX_TOOLWINDOW (defined as 0x00000080) style is turned on. If WS_EX_APPWINDOW is turned on, the taskbar shows a button for the window, and if WS_EX_ TOOLWINDOW is turned on, the taskbar does not show a button for the window. You should never create a window that has both of these extended styles.
You can create a window that doesn't have either of these styles. If a window has neither style, the taskbar decides to create a button if the window is unowned and does not create a button if the window is owned.
One final note: before making any of the above tests, the taskbar first checks to see if a window has the standard WS_VISIBLE window style turned on. If this style bit is off, the window is hidden; the taskbar never shows a button for a hidden window. Only if the WS_VISIBLE style bit is on will the taskbar check the WS_EX_APPWINDOW, WS_ EX_TOOLWINDOW, and window ownership information.
Reg : "Well, what Jesus blatantly fails to appreciate is that it's the meek who are the problem."
|
|
|
|
|
Thank you both - I'd say I need to not set WS_EXxxxWINDOW, hopefully as my Window is owned ( I presume this means it has a parent that is not NULL ), setting WS_CAPTION | WS_SYSMENU etc. will fix the problem.
Christian
As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet.
Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
