|
Did you call RedrawWindow() for the bar after its modification ? 
class AnyBody
{
protected:
AnyBody();
virtual void BeHappy() = 0;
public:
virtual ~AnyBody();
friend class Air;
friend class Water;
friend class Fire;
friend class Earth;
};
|
|
|
|
|
I did, but not sure if its done right.
I have something like this:
m_WndToolbar.AddBitmap(1,IDB_Bitmap1);
RedrawWindow();
Not sure how or if I have to specify the rect structure for the RedrawWindow() function?
|
|
|
|
|
Try it :
m_WndToolbar.SetButtonInfo(1 ,
IDC_COMMAND2 ,
TBBS_BUTTON,
0 );
m_WndToolbar.RedrawWindow();
class AnyBody
{
protected:
AnyBody();
virtual void BeHappy() = 0;
public:
virtual ~AnyBody();
friend class Air;
friend class Water;
friend class Fire;
friend class Earth;
};
|
|
|
|
|
It didn't work for me. Does it work for you?
|
|
|
|
|
I'm using CMFCToolBar now...
...but you could debug the SetButtonInfo(..) by F11
to verify that the old button will be deleted and the new inserted
(or set a breakpoint at
bartool.cpp :<br />
void CToolBar::_SetButton(int nIndex, TBBUTTON* pButton) )
class AnyBody
{
protected:
AnyBody();
virtual void BeHappy() = 0;
public:
virtual ~AnyBody();
friend class Air;
friend class Water;
friend class Fire;
friend class Earth;
};
|
|
|
|
|
Hi,
if we use cstring like,
CString errorDescription;
errorDescription.Format(L"Connected to %s\\%ld", m_hostAddress(/*cstring type*/),Literals::CONFIGURATION_SERVER_PORT(/*int type*/));
here,instead of cstring if i use std::string errorDescription,
then how the above format can be done?
thanx.
|
|
|
|
|
|
You can use ostringstreams as described in the previous reply, or you could use Boost.Format[^], which gives you an interface more like CString::Format.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
CodeProject MVP for 2010 - who'd'a thunk it!
|
|
|
|
|
Hello,
I want to find the handle of same windows currently opened.
E.g: I have started 2 notepads and I want to get handle of both notepads using some windows APIs.
I tried FindWindow(). But its only return the first notepad window handle.
Any other APIs available for getting the handle of second Window?
Please help.
-Cvaji
|
|
|
|
|
Maybe try EnumWindows[^].
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
|
|
|
|
|
Code-o-mat wrote: Maybe try EnumWindows[^].
But this will enumerate all the top level windows right?
I have the window name/window class of my required window.
I need to get only that specific windows.
-Cvaji
|
|
|
|
|
You can implement the filtering in the callback function, you can get the window's "name" by calling GetWindowText[^] and the class name by calling GetClassName[^], althorough i am not sure that GetClassName works on windows in different processes...
If you know the Process ID's of the notepad apps you started you can also use GetWindowthreadProcessId[^] to recognize them.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
|
|
|
|
|
If there is no other simple way, i have to go with this option.
Thank you for the reply.
|
|
|
|
|
You could also try using FindWindow as you did, and once you find a window, do whatever you want with it and then add a space at the end of its name (title) and then use FindWindow again until it does not find any such windows anymore, you might want to remove the extra added space when you are done, of course this would be quite an unelegant and ugly solution...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
|
|
|
|
|
You mean the below code will return the handle for second notepad ? 
hWnd = ::FindWindow( 0, L"Untitled - Notepad " );
-Cvaji
|
|
|
|
|
No, i mean something like this:
HWND hWnd;
while ((hWnd = ::FindWindow(0, L"Untitled - Notepad")) != NULL)
{
::SetWindowText(hWnd, L"Untitled - Notepad ");
}
Since you add a space at the end of the window text, the next time you call FindWindow, it will not find this window you already used (since it's title does not mach your search string anymore) and go on looking for the next one, if you find that next one, you add a space to that one too and so on untill you get no more windows...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
|
|
|
|
|
Wow.
Hats off you man 
even though its an ugly method, i congratulate your brilliancy 
But I got another method.
HWND hWnd = ::FindWindow( L"Notepad", 0 );
hWnd = ::FindWindowEx( 0, hWnd, L"Notepad", 0 );
-Cvaji
|
|
|
|
|
Gee, thanks FindWindowEx, i better rememeber that for the next time
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
|
|
|
|
|
If FindwindowEx was not provided by MS, i would go for your suggestion.
|
|
|
|
|
Hello! I'm working on a library that's going to deal with windows (to be more specific, I'm wrapping some windows APIs that deals with window creation/destruction and messages (like a window click etc.) into OOP).
In the message handler this is what i have:
LRESULT CALLBACK zooppMessageHandler::msgHandler(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
zooppMessageHandler *obj = (zooppMessageHandler*)GetWindowLongPtr(hwnd, GWLP_USERDATA);
int retVal = false;
if(obj == NULL)
if(msg == WM_CREATE || msg == WM_INITDIALOG)
{
SetWindowLongPtr(hwnd, GWLP_USERDATA, LONG_PTR(((CREATESTRUCT*)lParam)->lpCreateParams));
obj = (zooppMessageHandler*)GetWindowLongPtr(hwnd, GWLP_USERDATA);
retVal = obj->OnInit();
if(retVal != false)
return retVal;
else
return DefWindowProc(hwnd, msg, wParam, lParam);
}
else if(msg == WM_PARENTNOTIFY && wParam == WM_CREATE)
{
}
retVal = obj->Handle(msg, wParam, lParam);
if(retVal != false)
return retVal;
else
return DefWindowProc(hwnd, msg, wParam, lParam);
}
I know that so far it may look a bit unprofessional/unoptimized but i don't care about that yet. As you may see, for normal windows I pass the 'this' pointer into CreateWindowEx() function, and attach it's address to the window's handle with SetWindowLongPtr(). When a message (other tham WM_CREATE, WM_INITDIALOG etc.) comes I just grab the address of 'this' by calling GetWindowLongPtr() and then handle the message.
But...I ran into a problem regarding child windows. As far as I'm aware, when a child window is created the system won't send a WM_CREATE message but instead it will send a WM_PARENTNOTIFY message, wParam contains the child window's message (in my case WM_CREATE) and lParam it's handle. This means I can't pass the address of the object which issued the CreateWindowEx() function into the message handler.
Am I wrong? If no...how can i pass the object's address when creating child windows? For normal windows (as you see in the above code), I get the object's code from lParam which contains a pointer to a CREATESTRUCT structures in which member lpCreateParams points to the address of the object which issued a CreateWindowEx() function call.
|
|
|
|
|
You could try to implement an extended CreateWindowEx(..) for all windows :
HWND CreateWindowAndRegisterHandler(..)
{
HWND hwndResult = CreateWindowEx(..);
if (hwndResult) {
if (lpParam &&
RegisterHandler(..)) {
CYourBaseHandler* pcBaseHandler = (CYourBaseHandler*) lpParam;
pcBaseHandler->OnInit();
}
}
return hwndResult;
}...and then use/decrease the map in your callback...
virtual void BeHappy() = 0;
|
|
|
|
|
Hmm..indeed! I know what I have to do. Thanks for the tip!
I'll get to work immediately !
|
|
|
|
|
Is there an API to know the current idle-status percentage of the cpu usage (like what is showed in the taskmanager)?
Russell
|
|
|
|
|
|
Hi,
Dll best practices document from Microsoft available Here recommends avoiding use of memory management function from the dynamic C Run-Time (CRT) within DllMain. But DllMain function of MFC Extension DLL is dynamically allocating the memory for CDynLinkLibrary in the code snippet available at MSDN.
Is it a violation of Dll Best Practices or ok to use in MFC extension DLL?
thanks
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
