|
He was just having problems getting the location of his anchor button on the screen to replace with one he was drawing out... but I think he realized his operations weren't all on what item he needed.
|
|
|
|
|
GetWindowRect() should work once you've converted coordinates using ScreenToClient() and assuming you've done the operation on the correct item.
For example, if you want the location of an anchor button:
CWnd *anchor = GetDlgItem(IDC_BUTTON);
RECT anchor_rect;
anchor->GetWindowRect(&anchor_rect);
ScreenToClient(&anchor_rect);
|
|
|
|
|
Thanks.
I was doing ScreenToClient on the wrong item!
Works as advertized.
Vaclav
|
|
|
|
|
Happens... glad you've got that all worked out... don't forget to vote! 
|
|
|
|
|
Hi,
I am using visual studio 2008 MFC feature pack. My application has a "quick access toolbar" which is included in the MFC feature pack (it can be found at the top left of the main window. right next to the main menu).
My application is localized to several languages. Unfortunately, I can't find a way to translate the quick access toolbar and it's sub enries ("More Commands...", "Show Below the Ribbon" and "Minimize the Ribbon").
Does anyone know how to translate the quick access toolbar?
Thanks,
Kobi.
|
|
|
|
|
I am getting following error, where my program somehow using SetGUIDValue function.
Error 7 error C2664: 'A_StringFromGUID2' : cannot convert parameter 2 from 'OLECHAR [64]' to 'LPSTR' c:\program files\microsoft visual studio 9.0\vc\atlmfc\include\atlbase.h 5696
Regards
|
|
|
|
|
OLESTR's are unicode (ie, 16bits per character) and LPSTR is not-unicode (ie, 8bits per character).
So, I'm guessing you have a unicode / not-unicode problem.
Our usual cure here is to suggest people read the following article:
The Complete Guide to C++ Strings, Part I - Win32 Character Encodings[^]
Feel free to rate the article well if it helps you,
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
Hi!
I've shown a new Dialog On clicking a button in another Dialog using the following code:
CNewDialog *Ptr=new CNewDialog();
Ptr->Create(IDD_DIALOG1,this);
Ptr->ShowWindow(SW_SHOW);
My problem is When I click the first Dialog, Focus doesn't switch to the first Dialog.
I've to minimize the new Dialog, if I want to see the first Dialog. How to set Focus
to a Dialog while it is clicked or pressed ALT+TAB?
My first form is created like this:
UINT TransForm::ThreadExec1(LPVOID param)
{
DWORD result =0 ;
TerminateThread(Retry::ThreadExec, 0);
TerminateThread(TransForm::ThreadExec, 0) ;
IndForm ObjIndForm;
AfxGetApp()->m_pMainWnd = &ObjIndForm;
ObjPtrIndForm=&ObjIndForm;
glo_error=3;
ObjIndForm.DoModal();
return result;
}
However,I can't change the code for the two Dialog's creation.
modified on Monday, June 27, 2011 4:54 AM
|
|
|
|
|
I can see some problems:
1/ Unless you *really* know what you're doing it's a bad idea to create UI objects from multiple threads. It's like juggling with loaded guns whilst drunk. Sure, it may seem like a good idea at the time, but someone's gonna lose a toe.
2/ TerminateThread is also a really bad idea. I don't think I have *ever* used it. I've used plenty of Events, and BOOL's, and WaitForSingleMessage (hSomeThread, dwA_short_time)'s, but never TerminateThread.
That way memory leaks and crashes lie.
3/ To answer your actual question...
Ptr->SetFocus () ?
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
Iain Clarke, Warrior Programmer wrote: I can see some problems:
1/ Unless you *really* know what you're
doing it's a bad idea to create UI objects from multiple threads. It's like
juggling with loaded guns whilst drunk. Sure, it may seem like a good idea at
the time, but someone's gonna lose a toe.
2/ TerminateThread is
also a really bad idea. I don't think I have *ever* used it. I've used plenty of
Events, and BOOL's, and WaitForSingleMessage (hSomeThread, dwA_short_time)'s,
but never TerminateThread.
That way memory leaks and crashes
lie.
3/ To answer your actual question...
Ptr->SetFocus ()
?
Iain.
Inside which Event?
|
|
|
|
|
You showed two pieces of code. Only one has "Ptr" in it. Look up SetFocus on msdn for more information on that member function. The name is a bit of a give away though.
The second piece of code you showed implied you have threads creating dialogs. My points about threads and TerminateThread applied to all windows programs, not just the bits you shows.
Just in case I misunderstood your question, when I used "Event" above, I meant Win32's event synchronisation objects, created by
CreateEvent win32 function.
If you've not heard of them (and mutexes [*], and semaphores) then you really should not be creating windows outside the main thread. I may sound harsh, but I simply mean you should not be using them *yet*. Do some reading, play with some programs, understand the ideas, then go wild.
Read
http://www.flounder.com/uithreads.htm[^] and have a browse through flounder's other articles. I don't agree with everything he says, but the vast majority of it is spot-on.
Iain.
[*] mutices?
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
ObjIndForm.ShowWindow(SW_SHOW)
|
|
|
|
|
not working. Crashes at crtexec.c at the following code:
(HINSTANCE)&__ImageBase,
NULL,
lpszCommandLine,
StartupInfo.dwFlags & STARTF_USESHOWWINDOW
? StartupInfo.wShowWindow
: SW_SHOWDEFAULT
);
|
|
|
|
|
Here is the scenario
I have developed a custom class as below:
InsertEdit.h
class CInsertEdit :
public CWnd
{
DECLARE_DYNAMIC(CInsertEdit)
...
protected:
...
afx_msg void GetCustomerName();
afx_msg void GetInitialBalance();
afx_msg void GetPhoneNumber();
afx_msg void GetDateOfBirth();
afx_msg void GetCountry();
...
};
InsertEdit.cpp
#include "InsertEdit.h"
#define INSERTWINDOWCLASS L"INSERTWINDOWCLASS"
...
BEGIN_MESSAGE_MAP( CInsertEdit, CWnd)
ON_WM_CTLCOLOR()
ON_WM_CREATE()
ON_WM_PAINT()
ON_COMMAND(TEXT_2,GetCustomerName)
ON_COMMAND(TEXT_3,GetInitialBalance)
ON_COMMAND(TEXT_4,GetPhoneNumber)
ON_COMMAND(TEXT_5,GetDateOfBirth)
ON_COMMAND(TEXT_6,GetCountry)
END_MESSAGE_MAP()
IMPLEMENT_DYNAMIC(CInsertEdit, CWnd)
...
afx_msg void CInsertEdit::GetCustomerName()
{
wchar_t cst[256];
UserName.GetWindowTextW(cst,256);
MessageBox(cst,L"Test",MB_OK);
}
...
I am expecting that any type of command like "Click" or "key stroke" will call the GetCustomerName function called. but it is not.
CInsertEdit is a custom class with few edit class in it..
Am I missing anything?
Shall I have to add anything special on main Window class or anywhere else?
|
|
|
|
|
Looking at your code (and I am far from being an expert on MFC) the only time that function will be called is via the TEXT_2 command. How does this command get invoked?
The best things in life are not things.
|
|
|
|
|
Richard MacCutchan wrote: Looking at your code (and I am far from being an expert on MFC) the only time that function will be called is via the TEXT_2 command. How does this command get invoked?
TEXT_2 this is not a command. Its just a Macro constant.
ON_COMMAND macro create a set of code that ensure the call of the function.
|
|
|
|
|
johny10151981 wrote: ON_COMMAND macro create a set of code that ensure the call of the function.
I guess you don't understand what the purpose of the ON_COMMAND macro is. Adding this to your program creates the code that will be called when the TEXT_2 command is invoked by the user. If you do not have any way of invoking the TEXT_2 command then this code will never run.
The best things in life are not things.
|
|
|
|
|
I dont get it..........
Since when
TEXT_2 is a command?
|
|
|
|
|
johny10151981 wrote: Since when
TEXT_2 is a command?
Since you put it in the ON_COMMAND macro.
Another example of an ON_COMMAND macro:
ON_COMMAND(ID_FILE_NEW, OnFileNew)
The ON_COMMAND macro in a message map is a way of telling the message mapper what to do with a WM_COMMAND windows message that has WPARAM=command id. In the case I wrote, wParam equals ID_FILE_NEW.
In the case you wrote, wParam equals TEXT2.
So, unless somewhere else in your code issues WM_COMMAND,wParam==TEXT2, your function will never get called. That other place could be window's menu handler, or the MFC code behind a toolbar, or a dialog button, or...
In another reply, you say TEXT2 is a macro. Do you mean:
#define TEXT2 1234
or something more complex?
Another problem you could be having is message routing. MFC does lots of work behind the scenes to give your objects the ability to response to commands. For example, CDocument never has a window, but it can respond to WM_COMMANDs.
Read this classic article from 1995. The re-read it. Then program a bit, then re-reread it. If you can't absorb it pretty well, you will struggle with MFC, and most windows programs. .Net may do things differently, but many of the principles are the same.
Meandering Through the Maze of MFC Message and Command Routing[^]
Don't forget to bookmark it!
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
Thanks for the link, I've been looking for a decent explanation of this for years!
The best things in life are not things.
|
|
|
|
|
It really is a great article. It opened my eyes to many possibilities for more self contained objects, and plug in architectures.
It greatly reduced spaghetti.
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
Thank you for your reply and the link.
I guess I will get my answer in that link. As I have told, I didn't build that application using MFC Wizard. And I am not using any other class other than CWnd.
Thanks again
|
|
|
|
|
johny10151981 wrote: And I am not using any other class other than CWnd.
I'm finding it hard to believe you have a working MFC application then. MFC's message loop "live"s in CWinThread::Run member class. (CWinApp inherits from CWinApp).
And without a message map, you won't get a working application.
I suppose you could write a "raw" Win32 WinMain, and message pump yourself, and just use MFC's CWnd (and other CWnd based classes, like CEdit) as wrappers around a basic HWND windowa handle, but in that case you won't have any message mapping working, etc.
So, maybe that's the problem! You're not really using MFC!
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
I am very much comfortable with win32 application(Non MFC). Even though i am not that experienced. Our Office using several win32 application developed by me(Mostly related with printing).
I am developing the same application that I have developed with PHP and MySQL. Though I am very good at php I dont like working with php. I am just trying to switch to Win32 Development.
So, all I am doing is improving myself(so far for no purpose).
Application is running. I am receiving notification from TreeControl.
If I would have developed this in plain C++ It would be finished 50% by this time. But developing in plain C/C++ has some disadvantages, Developing is slower than MFC. I have started with raw MFC, the reason is to make myself more clear about the behavior of MFC
|
|
|
|
|
johny10151981 wrote: I have started with raw MFC, the reason is to make myself more clear about the behavior of MFC
I must applaud you, it does sound like you have the right idea. You're probably fed up of reading text from me, so I'll try to be brief:
Look at the definition of ON_COMMAND etc, and you'll see they're just filling in a variable for MFC's command routing classes to use. Unless you use those classes, MFC message maps will do *nothing*.
Use the MFC appwizard to make a very simple application. Add a command handler. Put a breakpoint there, and then see just how much work MFC does for even a trivial menu command handler.
The meandering article does cover the evolution from
switch (iMsg)
{
case WM_COMMAND:
switch (LOWORD(wParam))
{
case ID_MY_COMMAND:
to message maps.
Good luck in your explorations!
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
