|
I have a CFormview based SDI application. On the formview, I have a property sheet displayed, which has quite some edit controls.
Although I have specified accelerator keys in the resource, the program never respond to any key press. So I am thinking of CMyView::PreTranslateMessage, then CMyView::WindowProc, but neither of them can capture wm_char message when I pressed any key when the edit control on property page is having the input focus.
what can I do? Thanks a lot!
|
|
|
|
|
It's just a guess, i don't use the MFC framework, but don't the WM_CHAR messages only get sent to the actual edit window?
Try using GetWindow() to get the handle of the edit control, and then run a loop using GetMessage() to get the first message in the message queu. Then check it for WM_CHAR and ...
It's just a guess though, there's probably an easier way 
Kuniva
--------------------------------------------
|
|
|
|
|
I am not sure. But in one article Nish wrote, you can use PreTranslateMessage to capture wm_keydown or other messages by the dialog instead of having it processed by the control which have the input focus.
I think I should be able to do the same in my app. but 
The GetWindow() would be a messy one in my case even it works, since I have hundreds of edit controls.
any other hint?
|
|
|
|
|
Hi,
I am developing a Application which communicated with a Wireless
Protocol Stack on board,
through Serial Communication from a Windows XP m/c. through PPP packets. I
am using MFC API's
for sending data. Is there any mechanism to find out what actual data is
been sent through the COM port
and which protocol is used in sending. I mean the format of the data packets
and so..
Please respond soonly and it would be a great help for me..
Thanks,
pramodav@sasken.com
Pramod Kumar A
SASKEN-INDIA
|
|
|
|
|
Hi
I want to know the physical size of my monitor in inches/millimeters/centimeters. This is what I do currently:
CDC dcDisplay;
if(!dcDisplay.CreateDC("DISPLAY", NULL, NULL, NULL))
{
MessageBox("Failed to get display DC.", "Error", MB_OK|MB_ICONEXCLAMATION);
ExitProcess(0);
}
int xDPI = dcDisplay.GetDeviceCaps(LOGPIXELSX);
int yDPI = dcDisplay.GetDeviceCaps(LOGPIXELSY);
int xRes = dcDisplay.GetDeviceCaps(HORZRES);
int yRes = dcDisplay.GetDeviceCaps(VERTRES);
int xInches = xRes / xDPI;
int yInches = yRes / yDPI;
const double dInchToMillimeter = 25.4;
double xMillimeter = xInches * dInchToMillimeter;
double yMillimeter = yInches * dInchToMillimeter;
So I get 13 Inches horizontal (330,2 mm) and 10 Inches vertical (254 mm).
But there's another method, that outputs something different:
int xMillimeter = dcDisplay.GetDeviceCaps(HORZSIZE);
int yMillimeter = dcDisplay.GetDeviceCaps(VERTSIZE);
Outputs 320 mm horizontal and 240 millimeters vertical.
Which method is more trustful? One more thing: If I measure
my display with a ruler it seems that all values determined by both functions are too small, e.g. it seems that my display has a width of at least 350 mm and a height of at least 260 mm
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
From what I understand of it, there is no really accurate way to determine the monitor size.
|
|
|
|
|
Windows assumes the monitor's resolution is 96dpi. There's no way that your program can accurately work out how big the monitor is, unless you look in the registry for the monitor model and lookup a database...
Ryan
Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2nd April 2003, The Lounge)
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"
|
|
|
|
|
I have a Dialog project that when compiled will only show the MFC Icon with Windows Explorer. If you click on the file and display properties, then the Icon displayed is the one that I created for it.
Any suggestions as to what I am doing wrong.
Thanks in advance.
Eldon Zacek
Czech-Mate Enterprises, LLC
|
|
|
|
|
Change both the 32x32 sized icon AND the 16x16 and your problem may be fixed.
-KMAZ
|
|
|
|
|
In the VC++ icon editor, there are several available icon types. The one that is normally displayed with your app is the 32x32 size but a second one is also created by default of size 16x16. Explorer usually uses the smaller one. To fix your problem, redraw the smaller one too and rebuild your app.
I am always doing this myself too.
|
|
|
|
|
You have to make sure that there is a 16x16 icon in the icon itsef. Open the icon in Visual Studio and make sure there is a 16x16 version of the icon.
Regards,
Brian Dela
|
|
|
|
|
I want to do the same that MFC do when the New Document option in Menu is pressed.
What I have to call?
I've tried Doc->OnNewDocument() but is not the same, because the view is not refreshed. I think the call has to be related to OnFileNew of app but I don't know what's the correct sintaxis.
Best Regards
Dr.Pi
|
|
|
|
|
How about the following:
AfxGetMainWnd()->PostMessage(WM_COMMAND,ID_FILE_NEW);
|
|
|
|
|
|
I have a problem at the middle of my work. I don't want to restart from the beginning.
Right now, I am writting a software in C++ with MFC. I use the Message MAP builded by the Wizard. I don't want to tell what kind of software I do because it is confidential. This is a tool used on PC, which communicate with an embedded system.
I don't need a real time software, the time is not critical. We also want something friendly. That is why my interface is Window. At this time, everything work, for the futur, I see a problem.
The problem is the following:
-----------------------------
When a process is currently running (not finish), I want to exit from my function, do something else, and come back to see if I have the result of that process or exit if the timeout is elapsed. To do so, I need to Dispatch the Message
by myself like the old method with the Windows Procedure and the switch case with different messages. I know very well how to do it but now, I have a software with a message map. Bad or good decision, I am not sure at this time.
My solution is to restart a new project with old fashion and control all message with the switch case (no message map). I can also recuperate all my files.
Other problem, the old method use HANDLE, MFC doesn't.
Is there something I don't understand ????
Please, help !
Danny
|
|
|
|
|
MFC map is the switch statment just add your message to it
|
|
|
|
|
I am not sure what the problem is but there should be an easy solution with mfc. Can you execute your function in a seperate thread?
If you want the old switch / case all you have to do is override WindowProc(). I did this in a directdraw application.
Danny Gilbert wrote:
Other problem, the old method use HANDLE, MFC doesn't.
What do you mean here. In most cases in MFC you have access to the handle.
John
|
|
|
|
|
You can make your own message pump wherever you want with this code:
if(::PeekMessage(&msg,m_hWnd,0,0,PM_REMOVE))<br />
{<br />
::TranslateMessage(&msg);<br />
::DispatchMessage(&msg);<br />
}
to check for an event or message inside your function and the come back to your process.
Daniel Cespedes
"Santa Cruz de la Sierra Paraiso Terrenal!"
daniel.cespedes@ieee.org
|
|
|
|
|
If I understand, you says that I can stay in my process and call (for exemple at each loop) the PeekMessage, Translate and Dispatch Message functions !!!
So, Windows will execute the function (like refreshing the screen, etc.) and always come back at the caller, in my process.
Is it what you explain ?
|
|
|
|
|
exactly!!
Daniel Cespedes
"Santa Cruz de la Sierra Paraiso Terrenal!"
daniel.cespedes@ieee.org
|
|
|
|
|
God, you reminded me of doing background processing in Win16. Shame on you!! It took me a long time to forget!!
onwards and upwards...
|
|
|
|
|
well it works fine in my codes, and I have taken the code from Programming Visual C++ fifth Edition from Kruglinsky, a rather new book.
Is a method that sometimes makes multithreaded programming unnecessary.
greetings.
Daniel Cespedes
"Santa Cruz de la Sierra Paraiso Terrenal!"
daniel.cespedes@ieee.org
|
|
|
|
|
Multithreading does have its problems besides the difficulty with synchronizing shared objects, its harder to debug, and MFC doc / view does not support multithreading. However after you get over a few hurdles it is usually better to use unless you only have one background task.
John
|
|
|
|
|
I didn´t know that MFC doc/view doesn´t support multithreading, so if I want to use it I have to make a Dialog based app?
cheers!
Daniel Cespedes
"Santa Cruz de la Sierra Paraiso Terrenal!"
daniel.cespedes@ieee.org
|
|
|
|
|
John M. Drescher wrote:
MFC doc / view does not support multithreading
I didn´t know that MFC doc/view doesn´t support multithreading, so if I want to use it I have to make a Dialog based app?
cheers!
Daniel Cespedes
"Santa Cruz de la Sierra Paraiso Terrenal!"
daniel.cespedes@ieee.org
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
