|
here is my code for SPACE bar hanlder
CGDICarSampleDlg.cpp
void CGDICarSampleDlg::OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags)
{
if (nChar == 8) {
myCar.Backward();
Invalidate();
}
else if (nChar == 32) {
myCar.Forward();
Invalidate();
}
else if (nChar == 80){
CColorDialog dlg;
if (dlg.DoModal() == IDOK)
{
color = dlg.GetColor();
}
red = GetRValue(color);
green = GetGValue(color);
blue = GetBValue(color);
char rr[32];
itoa(red, rr, 10);
r = rr;
char gg[32];
itoa(green, gg, 10);
g = gg;
char bb[32];
itoa(blue, bb, 10);
b = bb;
myCar.m_brCar.Detach();
myCar.m_brCar.CreateSolidBrush(RGB(red, green, blue));
WritePrivateProfileString("car", "red", r, "car.ini");
WritePrivateProfileString("car", "green", g, "car.ini");
WritePrivateProfileString("car", "blue", b, "car.ini");
myCar.PickColor();
Invalidate();
}
else {
TRACE( "others" );
}
CDialog::OnKeyDown(nChar, nRepCnt, nFlags);
}
and here is the command triggered
Car.cpp
void CCar::Forward()
{
m_nCarX += 5;
angleFlag = angleFlag + 1;
}
void CCar::Backward()
{
m_nCarX -= 3;
angleFlag = angleFlag - 1;
}
if i SetFocus on the Main Dlg Window, will it kill the focus of the button?
|
|
|
|
|
One option is to allow the user to trigger the colour pick button by mouse click only. On Key down events, process the movements of your car. Override PreTranslateMessage() of your window to handle all key down events.
void CGDICarSampleDlg::OnBnClickedButtonColour()
{
}
BOOL CGDICarSampleDlg::PreTranslateMessage(MSG* pMsg)
{
if(WM_KEYDOWN == pMsg->message)
{
KeyDownHandler(pMsg->wParam);
return TRUE;
}
return CDialog::PreTranslateMessage(pMsg);
}
void CGDICarSampleDlg::KeyDownHandler(UINT nChar)
{
if (nChar == 8)
{
}
else if (nChar == 32)
{
}
}
|
|
|
|
|
i just tried this code:
BOOL CGDICarSampleDlg::PreTranslateMessage(MSG* pMsg)
{
if(WM_KEYDOWN == pMsg->message)
{
OnKeyDown(pMsg->wParam);
return TRUE;
}
return CDialog::PreTranslateMessage(pMsg);
}
got an error saying
error C2660: 'CGDICarSampleDlg::OnKeyDown' : function does not take 1 arguments
maybe because OnKeyDown needs three not just one, on my code below notice that the OnKeyDown event has 3 return values,.
CGDICarSampleDlg.cpp
void CGDICarSampleDlg::OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags)
{
if (nChar == 8) {
myCar.Backward();
Invalidate();
}
else if (nChar == 32) {
myCar.Forward();
Invalidate();
}
else {
TRACE( "others" );
}
CDialog::OnKeyDown(nChar, nRepCnt, nFlags);
}
declaration of OnKeyDown ...
CGDICarSampleDlg.h
afx_msg void OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags);
|
|
|
|
|
hey that is not the WM_KEYDOWN message handler. You don't need it anymore. 
BOOL CGDICarSampleDlg::PreTranslateMessage(MSG* pMsg)
{
if(WM_KEYDOWN == pMsg->message)
{
KeyDownHandler(pMsg->wParam);
return TRUE;
}
return CDialog::PreTranslateMessage(pMsg);
}
void CGDICarSampleDlg::KeyDownHandler(UINT nChar)
{
if (nChar == 8)
{
}
else if (nChar == 32)
{
}
}
|
|
|
|
|
yup i did that already but it seems that i still get the same error..
KeyDownHandler does not take 1 argument...
you might want to check the sample project, here's the link and take a look... i did not include the button yet.. run and see..
http://hotfile.com/dl/68100441/675ae33/GDICarSample.rar.html[^]
meybe am just too dumb to get your point, haha, sory..
take a peek at my code to understand what i want do do.. thanks for help man, appreciate it.
modified on Monday, September 13, 2010 11:56 PM
|
|
|
|
|
|
thanks man, i got alot of hints to get my car going on track. it's working fine man. your code works well..
|
|
|
|
|
Hi everyone. I have declared an fstream object that I would want it to either support unicode characters or not. I am using a preprocessor to do this as shown in the code below. Please I am not an advanced programmer in C++, that's why I am consulting experts here to know if it is right.
#if defined (_UNICODE) || defined (UNICODE)
#define fstream basic_fstream<wchar_t,char_traits<wchar_t>>
#else
#define fstream basic_fstream<char, char_traits<char>>
#endif
I have limited knowledge in this C++ template. If it is not right, how should I write it. Thanks in advance.
|
|
|
|
|
I think you should use typedef instead:
#if defined (_UNICODE) || defined (UNICODE)
#typedef basic_fstream<wchar_t,char_traits<wchar_t>> fstream
#else
#typedef basic_fstream<char, char_traits<char>> fstream
#endif
|
|
|
|
|
Good idea, however you should check the syntax of the posted code.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
You don't want to use fstrean as something you typedef or define. ESPECIALLY define...
Use a typedef and don't use a name that's already in use by the standard library - unless you understand namespace overloading rules you'll have a few surprises, even if you do you might still end up with surprises. Another way you could do it for MS compilers is to rely on that old chestnut TCHAR being defined correctly for the build you're doing and then just use a single typedef:
typedef std::basic_fstream<TCHAR> file_stream;
The final point to make is... On windows, why bother? Unless you've got some rubbish old Windows on DOS computers kicking around you can just use wchar_t and wfstream throughout your code.
Cheers,
Ash
|
|
|
|
|
What I want to do is that I will compile the same application as either unicode or non-unicode without modifying the source code. I also do not want to assume the use of Windows. Maybe I have to use the typedef rather if that is better or the best way.
|
|
|
|
|
Personally I wouldn't bother with the effort of abstracting stuff to have different builds for different character widths. These days use wchar_t (either UTF-16 on Windows or UCS4 on Unixy platforms) as the internal representation and char as the external representation (as UTF-8). Anything else tends to be overcomplicated and not really worth it in my experience.
If you really have to do that though you can define your own character type and get a similar effect to using TCHAR under windows (and, as a bonus, get rid of stuff in capital letters).
Cheers,
Ash
|
|
|
|
|
Another thing: do you really want to change the file format depending on how you build the application? That will imply you won't be able to read a UNICODE built app's data file from one built without it and vice versa. Would it not be nice to have a single file format, no matter how your app is built?
|
|
|
|
|
I am using Nuance's SAPI to create a voice recognition training box, which I call with their function:
hRes = m_dgnEngine->DlgShow( dgndlgGeneralTraining, NULL, CComVariant( ), CComVariant( ) )
while I don't think showing that function is important with regards to the question, the problem I am having is the window that pops up is centered on my primary monitor, but I really want it to open on a different monitor.
I cannot simply change the primary monitor in windows and I cannot create their window any other way.
I know I can get the handle of the window, but is there a way in C, C++, or VC++ to move a window that you, technically, have no control of?
modified on Wednesday, September 8, 2010 3:29 PM
|
|
|
|
|
So basicly, you are asking if there is a way to control something you have no control whatsoever of? Sounds like a 'no' to me.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
Kinda. I'm not sure if there's something that can manipulate dialog boxes in these languages. I want to think that there would be a way to somehow get to the wndproc messages and move the box.
Or perhaps there is a simple method to do this with the handle of the window.
|
|
|
|
|
With the handle you can use MoveWindow[^] or SetWindowPos[^], does that Show call you issue display the window and return or does it bring up a modal dialog and return only after it was dismissed? If it shows and returns you should be able to use the forementioned methods -if you have the window handle- to position it. Things might look a bit grim if the window that call shows is handler by some other-than-the-main-gui-thread.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
Looks like MoveWindow shot that message off to the dialog box to resize and move it. The dialog box is still functional too, so everything is looking good. If there's any problems now, I'll post a reply, but I do think this is answered as of right now.
There's so many methods in MFC, it's hard to keep up
Thanks a ton!
|
|
|
|
|
No probs, glad to help.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
You could try something along these lines:
- try and identify the window you want to move; e.g. use EnumWindows() and GetWindowText() to find the window based on it's title text.
- then send a WM_MOVE message using SendMessage. tell the window to move, I think by calling MoveWindow()[^].
This may or may not work; it would be easy to teach a window to be unmovable, but it isn't standard practice.
|
|
|
|
|
Isn't WM_MOVE[^] used to "tell" the window procedure that the window was moved rather then actually moving the window?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
I guess you're right (I'm no longer familiar with all the low-level Windows stuff); a simple MoveWindow()[^] should be sufficient!
|
|
|
|
|
|
Could you post your code? Maybe we can help you to fix it.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
