|
Does GetBestInterface() help? If not, there are other IP Helper functions available that may.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
I do some drawing on client area of main window, but some controls on main window covered the drawing. I have tried to use non-clipchildren style, but it doesn't work. Does anyone know how to solve the problem?
Thanks
|
|
|
|
|
I don't think this is possible in any dependable way. If you want parts of the controls transparent, you might want to investigate SetWindowRgn. Hiding the controls under some circumstances might perhaps be another alternative?
|
|
|
|
|
Hello
I write an application (MFC Dialog), when i call GetTitleBarInfo, the compiler alway error: undeclare identifier
i know this function declare in winuser.h, and i already check,
i use VC6++, SP5, instal Platform SDK
Any one can help me.
Thanks alot
|
|
|
|
|
|
#define WINVER 0x0500 (Before including any windows headers)
And i tried this in Win 2000.
|
|
|
|
|
Hi
Could someone tell me how I can accomplish string case conversion using STL string, something like MakeUpper() and MakeLower() in CString?
Thanks!
|
|
|
|
|
Use foreach with a funtion that calls toupper on each character in the string.
Christian
I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
|
|
|
|
|
Christian almost had it, but at least under my version of VC (.NET 7.0) toupper isn't passed the parameter by reference so you need to use std::transform
std::string str = "hello world";
std::transform(str.begin(),str.end(),str.begin(),::toupper);
If you can keep you head when all about you
Are losing theirs and blaming it on you;
If you can dream - and not make dreams your master;
If you can think - and not make thoughts you aim;
Yours is the Earth and everything that's in it.
Rudyard Kipling
|
|
|
|
|
Hello..
i've got a problem with threads and modeless dialogs.
With modal dialogs i had no problems. This is a mfc app(VC++6.0), in the main view, i created a button, and when i clicked on it i created a thread (which opened a dialog), then waited for the user to close the dialog, and delete the thread:
<br />
void CHilosView::OnButton1() <br />
{<br />
<br />
hilo = new CThread(); <br />
delete hilo;<br />
}
when i did the new CThread, it would create the dialog, when the user clicked on the cancel button of the dialog, the dialog would close, then it would get to the delete hilo line and it would be ok.
But now with modeless dialogs my function has become:
<br />
void CHilosView::OnButton1() <br />
{<br />
<br />
hilo = new CAccionarHilo();<br />
hilo->dlg->CThread(130); (dlg is a dialog, 130 it's id)<br />
hilo->dlg->ShowWindow(1);<br />
//delete hilo;<br />
}<br />
and i can't delete the thread there, because i would never be able to see the dialog!!.
So i'd love to be able to call the delete from the new dialog (that is created everytime i press button1 in the main window) 'cancel' button.
i can close the dialog, but i never get to delete the hilo (or thread (it's spanish))
I can't call the delete method as :'hilo' : undeclared identifier, and i can't include the hilosView header in the dialog class, because i include the Cthread file in the hilosView class, and it includes the dialog class.
hope you can help me!!
thanks!!
|
|
|
|
|
It's usually not a good idea to put a window/dialog in a secondary thread. You should post a user-defined message back to the main GUI thread to perform this service for you. If you really, really need to have GUI objects operating from a thread, you must not use a worker thread. You must use a user-interface thread, which has a message pump.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Hi,
I am have a program that uses serial port to transfer data from one machine to another. My program is actually running fine except for the problem that I have an intermittent scrambling of data received from the serial port. The bytes are actually interchanged position. Does anyone of you who knows this kind of problem ? Here is the sample data transmitted from the other machine. "test message" the data received by my program is like this "tets messgae"
then if I repeat it, sometimes the data is correct.
Any help is highly appreciated.!
Thanks,
Mar
Mar Solero Jr.
|
|
|
|
|
Thats impossible!
I think its a little bug in your code not a bug in serial comm.
Kamyar Souri
Booria CAD/CAM Systems
www.booria.com
|
|
|
|
|
i was just wondering how everyone gets there demo's and project's so small i just compiled a very small dialog it has 3 buttons 2 edits 1 combobox and 2 static text and its 2 mb i wanna know how to get it smaller
|
|
|
|
|
perhaps (in vb6.0)
project -> setting -> use MFC in a shared dll?
|
|
|
|
|
Did you compile it in debug mode?
|
|
|
|
|
1) VC++: Release < Debug build.
2) VC++: MFC: Shared Link < Static Link.
3) VC++: Win32 SDK < MFC.
4) Platform SDK Cmd-Prompt Build < VC++.
5) VC++ 7.x < VC++ 6.
Maxwell Chen
|
|
|
|
|
|
|
thanks mike that works wonders went from 2 mb to 236 kb 
|
|
|
|
|
Whether the dialog has 3 controls on it, or 23, the net result will be almost the same. Debug compilation aside, there are a lot of factors that go into why a file is a certain size, and why the size is misleading most of the time. Read this article to get a better understanding.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Hi, sorry for asking so many hook related questions, I'm new to them, and the people here have been very helpful, and I'm grateful for that. Basically I want to recieve all mouse and keyboard events, and selectively process and block them. I have a WH_GETMESSAGE hook, which looks something like the following:
LRESULT CALLBACK MouseProc(int nCode, WPARAM wParam, LPARAM lParam)<br />
{<br />
if(HC_ACTION==nCode)<br />
{<br />
MSG *pMsg=(MSG*)lParam;<br />
<br />
...<br />
<br />
pMsg->message=WM_NULL;<br />
lParam=(LPARAM)pMsg;<br />
}<br />
<br />
return CallNextHookEx(g_hHookMouse,nCode,wParam,lParam);<br />
}
This works fairly well, except some messages get through. The user can click to change windows, "restore" the window by clicking on the title bar, and I think just generally change the focus. I'm checking for and blocking these messages:
WM_LBUTTONDOWN
WM_LBUTTONUP
WM_LBUTTONDBLCLK
WM_MBUTTONDOWN
WM_MBUTTONUP
WM_MBUTTONDBLCLK
WM_RBUTTONDOWN
WM_RBUTTONUP
WM_RBUTTONDBLCLK
WM_NCLBUTTONUP
WM_NCLBUTTONDOWN
Are there additional messages I should consider? Or should I take a different approach?
Thanks a lot!
modified 12-Jul-20 21:01pm.
|
|
|
|
|
There is a more efficient way. A WH_GETMESSAGE hook will get called for every message that is retrieved with GetMessage() (incidentally, AFAIK, messages retrieved with PeekMessage() are not passed to the hook procedure). Processing every message in the system is extremely slow and inefficient.
A far better way would be to install keyboard and mouse hooks (WH_KEYBOARD and WH_MOUSE). That way, you get the keyboard and mouse events before they go in the message queue, and only process keyboard and mouse events.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
That was the way I originally implemented the hooks. The problem is that there doesn't seem to be a way to block both of the types of messages. The classic way seems to be to return -1, but that means that either the mouse or keyboard callback won't get called. Also, setting wParam=WM_NULL doesn't seem to work. So thats the reason I was trying to use a WH_GETMESSAGE hook. I'm open to suggestions on how to approach it though.
modified 12-Jul-20 21:01pm.
|
|
|
|
|
If you use WH_KEYBOARD_LL and WH_MOUSE_LL hooks and DO NOT call the CallNextHookEx, then the message will be blocked.
From the MSDN:
"Calling the CallNextHookEx function to chain to the next hook procedure is optional, but it is highly recommended; otherwise, other applications that have installed hooks will not receive hook notifications and may behave incorrectly as a result. You should call CallNextHookEx unless you absolutely need to prevent the notification from being seen by other applications."
We use the WH_KEYBOARD_LL to block ALT+TAB and other key combinations and it works great!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
