|
Check out WM_GETMINMAXINFO
Shog9
------
So they took me down to the gallows
And this boy, he said to me:
"Why do you smile, when the rope's around your neck?"
I said, "I tell you boy, when i get back..."
|
|
|
|
|
Okay. Everyone.
Do you add a handler in the mainframe class or the formview class (primary view)?
Kuphryn
|
|
|
|
|
Neither. Your view is contained within a MDI child window (MFC: CMDIChildWnd or derived); this window is the one that the user interacts with to resize, the one that displays the border and caption, and the one you need to add the handler to. If you've been using just CMDIChildWnd, you'll need to create a derived class and use that instead.
Shog9
------
So they took me down to the gallows
And this boy, he said to me:
"Why do you smile, when the rope's around your neck?"
I said, "I tell you boy, when i get back..."
|
|
|
|
|
Okay. Thanks.
I got it to work.
It is interesting that inside the WM_GETMINMAXINFO handler, we have to set the minimux x and y each time. In other words, if the user moves the border 100 pixels, then Windows calls WM_GETMINMAXINFO 100 times and have to set the minimux x and y 100 times. I wonder if there is a more elegant solution as in classing a function that will set the minimum x and y once.
Kuphryn
|
|
|
|
|
kuphryn wrote:
I wonder if there is a more elegant solution as in classing a function that will set the minimum x and y once.
Elegant != Win32, sadly.
Keep in mind, a lot of this originated back when memory was very precious, and windows were resized with those little rubberband-like things, so it probably made sense. Definately avoid heavy-duty calculations in the routine!
Shog9
------
So they took me down to the gallows
And this boy, he said to me:
"Why do you smile, when the rope's around your neck?"
I said, "I tell you boy, when i get back..."
|
|
|
|
|
Advice noted.
Another member mentioned OnSize() inside of the main frame. I do not see any advantage from OnSize() either size it is also called as the user resizes the Window via border.
Kuphryn
|
|
|
|
|
kuphryn wrote:
I do not see any advantage from OnSize() either size it is also called as the user resizes the Window via border.
Exactly. You could use OnSize(), OnSizing(), or OnGetMinMaxInfo() for this, but since the same thing has to be done no matter what it just makes sense to go with OnGetMinMaxInfo() and let Windows do the involved bits for you.
Shog9
------
So they took me down to the gallows
And this boy, he said to me:
"Why do you smile, when the rope's around your neck?"
I said, "I tell you boy, when i get back..."
|
|
|
|
|
kuphryn wrote:
if the user moves the border 100 pixels, then Windows calls WM_GETMINMAXINFO 100 times and have to set the minimux x and y 100 times
That is an artifact of the Window Full Drag feature of windows (When it updates the window while you are resizing or moving it). If this feature is off, you will get a WM_GETMINMAXINFO once so that windows knows where to create the boundaries to resize the window, then when the user lets go and finalizes the resize you will get a WM_WINDOWPOSCHANGING message which its default processor will generate one WM_GETMINMAXINFO, and finally after all of the sizing is done you will get a WM_WINDOWPOSCHANGED, which its default processor will generate another WM_GETMINMAXINFO message.
When the user has Full dragging selected, windows continually finalizes the sizing loop that is generated, in order to force a WM_NCPAINT and WM_PAINT messages to update the window. If the window finalizes this loop 100 times, you will actually get 200 WM_GETMINMAXINFO messages.
Each message has its purpose. When I spent some time looking at the messages that get generated behind the scenes, I was amazed at the sheer number of messages that were generated just to resize a window, or move the mouse.
Resetting the X and Y values each time the message is handled is the proper way to do it. If you do not do it, then windows will in the DefWindowProc. The best way to handle this message is to just have a set of cached values that you use when you want to change these values from the default.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
Okay. Thanks.
One final question. I got everything working correctly in OnSize(). As I resize the main frame and move objects according, sometimes the object gets out of scope and disappear. It is really weird. here is a quick example.
[ button ]
// Using MoveWindow()
// Resize main frame and move button to the right to keep it at the center.
[ but ]
It is like even though main frame expands, it does not consider the added area part of it.
What is the best solution?
Kuphryn
|
|
|
|
|
Okay. I figured out the problem. The problem was a logic and programming error, not MFC's fault.
Thanks everyone.
Kuphry
|
|
|
|
|
After getting the IHTMLCollection, and doing get_all etc,
and modifiying the element, the changes to the IHTMLTable
don't appear on the CHtmlEditView.
Any ideas?
<br />
IDispatch... GetHtmlDocument();<br />
...QueryInterface on IHTMLDocument2<br />
pDoc->get_all(&pCollect); <br />
pCollect->item(varID,varIdx, &pDocDisp );<br />
pDocDisp->QueryInterface(IID_IHTMLTable, (void**) &pElem);<br />
<br />
pElem->put_cols(cols);<br />
Thanks
Art
|
|
|
|
|
doing a invalidate(), updatewindow() could help.
or if you wanna save it, get_all again, and save it to the file and refresh it.
|
|
|
|
|
How do you programmatically select an item in a CListCtrl. It seems that there is no SetCurSel like function to achieve this.
Michel
It is a lovely language, but it takes a very long time to say anything in it, because we do not say anything in it, unless it is worth taking a very long time to say, and to listen to.
- TreeBeard
|
|
|
|
|
try:
m_myListCtrl.SetItemState(iIndex, LVIS_SELECTED, LVIS_SELECTED);
|
|
|
|
|
Check SetItemState and LVIS_SELECTED.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
it does not work, although it returns TRUE indicating success. The item is NOT selected in the list.
BOOL bSucceeded = m_MessagesList.SetItemState(iIndex, LVIS_SELECTED, LVIS_SELECTED);
Michel
It is a lovely language, but it takes a very long time to say anything in it, because we do not say anything in it, unless it is worth taking a very long time to say, and to listen to.
- TreeBeard
|
|
|
|
|
Ummm... It should work... Try calling m_MessagesList.SetFocus() first.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
That was the problem. Tx!
Michel
It is a lovely language, but it takes a very long time to say anything in it, because we do not say anything in it, unless it is worth taking a very long time to say, and to listen to.
- TreeBeard
|
|
|
|
|
If I create a windows application in Visual C++ using visual studio.net, will it run on windows nt???
Thanks in advance,
Paddy.
|
|
|
|
|
Why shouldn't it?
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Thanks for the help, I wasn't sure if it would work coz when I tried it with a C# program it complained of missing DLL's.
|
|
|
|
|
Yes, C# programs require the lastest DLLs for the .NET framework to work. But this also applies to Windows 95, 98 and other OS apart from NT.
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Cheers, Thanks for the help.
Paddy.
|
|
|
|
|
As long as you don't use any managed C++ code, a VC7 program will run on all versions of Windows.
Michael
"I've died for a living in the movies and tv.
But the hardest thing I'll ever do is watch my leading ladies,
Kiss some other guy while I'm bandaging my knee."
-- The Unknown Stuntman
|
|
|
|
|
It should, but keep this in mind:
1. Don't use any managed extensions - these require the .NET runtime. This can be installed on NT, though, but it's too new to be there by default.
2. Statically link to the MFC and Visual libraries. Otherwise, you may find the required DLL's do not exist on an NT system, and would have to be installed.
Even a broken clock is right twice a day.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
