C / C++ / MFC

12-Apr-02 7:07

Hello everyone,

I want to stop a CView-derived window from resizing below a certain size. I've tried overriding OnWindowPositionChanging() as follows:

void CPlaybackView::OnWindowPosChanging( WINDOWPOS *lpwndpos )
{
	UINT cx, cy;

	cx = lpwndpos->cx;
	cy = lpwndpos->cy;

	m_rcFrameHeader.SetRect(
		CXMARGIN, 
		cy - CYMARGIN - CYFH, 
		cx - CXMARGIN, 
		cy - CYMARGIN );

	m_rcScreen.SetRect(
		CXMARGIN, 
		CYMARGIN, 
		cx - CXMARGIN, 
		m_rcFrameHeader.top - CYMARGIN );

	if( m_rcScreen.Height() < 0 )
	{
		m_rcScreen.bottom = m_rcScreen.top;
		lpwndpos->flags |= SWP_NOSIZE;
	}

	CView::OnWindowPosChanging( lpwndpos );
}

but the window is still resizing. The contents isn't redrawn, coz my OnSize isn't called, but the window still resizes.

Do I have to override WM_GETMINMAXINFO? From my reading of MSDN this won't even be called coz I overrode WM_WINDOWPOSITIONCHANGING.

Anyone got any ideas?

TIA,

Pete

Tim Deveaux12-Apr-02 7:12

Tim Deveaux

12-Apr-02 7:12

Try _directly_ changing the values of the lpwndpos cx and cy values to the minimum (or maximum) sizes when they arrive out of bounds.

moredip12-Apr-02 8:10

12-Apr-02 8:10

No joy

Make no difference.

Any other suggestions anyone?

Paul M Watt12-Apr-02 8:15

Paul M Watt

12-Apr-02 8:15

WM_GETMINMAXINFO is the message that you want to override. This message is called right before the WM_ENTERSIZEMOVE message is called, indicating that the program is entering the modal size move loop. Window caches the min max information, and will not let the mouse track to a size any larger or smaller than the dimensions that you specified. This is how you can make it so that the user does not drag the window really tiny, then when they let go it snaps back to a larger size.

WM_GETMINMAXINFO is also called right after WM_WINDOWPOSCHANGING in order to verify that the min and max requirements are met for the window based on what the application sets inside of the handler for WM_WINDOWPOSCHANGING.

I think that your best bet is to handle WM_GETMINMAXINFO for min and max requirements, and anything that needs to be dealt with in between that range should be dealt with in WM_WINDOWPOSCHANGED.

Good Luck

Checkout my Guide to Win32 Paint for Intermediates

moredip12-Apr-02 9:01

12-Apr-02 9:01

Well I tried what you suggested, but Windows doesn't seem to want to call my OnGetMinMaxInfo() Frown | :(

I've got a CVideoView, which is derived from CPlaybackView, which is derived from - you guessed it - CView.

here's what I've got in CVideoView:

//CVideoview.h
...
	afx_msg void OnSize(UINT nType, int cx, int cy);
	//}}AFX_MSG
	afx_msg void OnGetMinMaxInfo( MINMAXINFO FAR* lpMMI );
	//afx_msg void OnWindowPosChanging( WINDOWPOS* lpwndpos );
...
DECLARE_MESSAGE_MAP()

//CVideoview.cpp
...
	ON_WM_SIZE()
	//}}AFX_MSG_MAP
	ON_WM_GETMINMAXINFO()
	//ON_WM_WINDOWPOSCHANGING()
...
ENDMESSAGEMAP()
...
...
void CVideoView::OnGetMinMaxInfo( MINMAXINFO FAR* lpMMI )
{
	TRACE( "In CVideoView::OnGetMinMaxInfo()" );
	lpMMI->ptMinTrackSize.x = CXVHC+CXMARGIN*2;
	lpMMI->ptMinTrackSize.y = CYVHC+CXMARGIN*3;
}

That TRACE() never prints Frown | :(

As you might have noticed, I commented out my overridden WM_WINDOWPOSCHANGING, cos I thought that might be why OnGetMinMaxInfo() wasn't being called. But it makes no difference.

I'm wondering what brain-dead mistake I've made Wink | ;)

Matt Gullett12-Apr-02 9:14

Matt Gullett

12-Apr-02 9:14

Try placing the code in your frame class instead of your view class.

moredip12-Apr-02 9:36

12-Apr-02 9:36

Great!

That's fixed it. It's working just right now.

Thanks a lot for all your help guys, today was an enjoyable day in school Big Grin | :-D

Pete

Paul M Watt12-Apr-02 9:43

Paul M Watt

12-Apr-02 9:43

I am sorry about misguiding you to use the view class, my mind was on one of the earlier questions that related to painting through the view class.

I am glad that you solved your problem though.

kilowatt

Checkout my Guide to Win32 Paint for Intermediates

moredip12-Apr-02 10:03

process crash on dual processor Winnt4 server

12-Apr-02 10:03

No problem, you set me on the right track, which was more important. Plus I learned some more about how windows deals with resizing, painting etc.

I appreciate it Smile | :)

Jim Crafton12-Apr-02 6:47

12-Apr-02 6:47

OK I have a program (console app) that gets connected to via sockets from another machine and then it just gets sent data repeatedly (financial data feeds). The program has to run 24/7, but on the multi processor box (Winnt4 sp5 dual Intel) it always crashes. The longest I have gotten it to run so far is about 12 hours. When the program runs on Winnt4 Server with a single processor it seems to work better (at least no crashes). Ditto with Windows 2K Worstation.
Are there special libs you need to link with or provide when running on a multi processor box ? I have never done anything like this so forgive what may be a stupid question Smile | :)

The program is a multi-threaded program, running in release mode

Tim Deveaux12-Apr-02 7:03

Tim Deveaux

12-Apr-02 7:03

Quick fix - use the /ONECPU switch in the boot.ini file! Smile | :)

But seriously folks...

The conventional wisdom is that you haven't tested your multithreaded app until you've tested it on a multi-processor machine.

The HAL and ntoskrnl _are_ different for multiple cpu boxes, but nothing else AFAIK.

Sounds like a fun one. (Feel free to vent at me for that Smile | :)

)

Jim Crafton12-Apr-02 7:17

12-Apr-02 7:17

Tim Deveaux wrote:
Feel free to vent at me for that

Nah! Smile | :)

I kind of figured this would be the case...sigh...
I wish I knew where to look though, maybe we'll just say that our software only runs on single processor machines Smile | :)

, yeah that's the ticket, and you can only run our program, yeah, and then ....

Grrr...back to pulling out my hair

Tim Deveaux12-Apr-02 7:21

Tim Deveaux

12-Apr-02 7:21

I _think_ the main area to look at is data access.

On a single CPU, threads are switched in a 'more' serialized fashion - while one might be preempted before finishing what its tweaking, it doesn't need to worry about some other identical code running concurrently on another processor - so I guess I'd look at shared data sections etc.

But, yes, pulling hair is good. Assuming you have some to spare. Not all of us do...

Jim Crafton12-Apr-02 7:58

12-Apr-02 7:58

by shared data do you mean stuff like the lists that the various threads work with and share ? On my app I have a singleton application class that contains a set of lists. The threads have access to the lists - write access is protected by using mutexs.

Tim Smith12-Apr-02 8:03

Tim Smith

12-Apr-02 8:03

What about read access? If someone is reading, you can't have anybody else write.

Also, if your shared data isn't shared over multiple processes and your locks will be very shortlived, then use a CRITICAL_SECTION and not a mutex. A CS performs much better.

Tim Smith

I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?

Jim Crafton12-Apr-02 8:05

12-Apr-02 8:05

I'll double check this. Thanks

James R. Twine12-Apr-02 7:43

James R. Twine

12-Apr-02 7:43

Jim Crafton wrote:
I kind of figured this would be the case...sigh...

Eek! | :eek:

Incorrect software development strikes again! Smile | :)

   FWIW, tracking things like this down are really not that hard.  It was already said that you should look at shared memory locations (shared variables), but you then should extend that search to code in and around Critical Sections, and code near InterlockedIncrement(...) and InterlockedDecrement(...).

   IME, those locations are the best place to find mistakes (or misunderstandings).

Jim Crafton also wrote:
maybe we'll just say that our software only runs on single processor machines[...]

   A very dirty thing you can do is to launch the app with a little helper application that uses CreateProcess(...) to launch your application with the CREATE_SUSPENDED flag, and you can then use the SetProcessAffinityMask(...) function to force the thing to run on one CPU.  Note that this is not a fix, nor is it The Right Thing to do, but it should work...!

   Peace!

-=- James.

Mike Nordell13-Apr-02 20:59

Mike Nordell

13-Apr-02 20:59

maybe we'll just say that our software only runs on single processor machines

I hope you'll never need it, but if you can't find the bug(s) you could limit the process to one CPU using SetProcessAffinityMask.

James R. Twine15-Apr-02 2:54

James R. Twine

15-Apr-02 2:54

Mike Nordell wrote:
I hope you'll never need it, but if you can't find the bug(s) you could limit the process to one CPU using SetProcessAffinityMask.

Must be a delayed echo... Big Grin | :-D

Peace!

-=- James.

Tim Smith12-Apr-02 7:56

Tim Smith

12-Apr-02 7:56

Somewhere you have some data that is being shared between two threads in your application. This memory is not being properly locked for access. Anytime you modify/read memory shared by multiple threads, you have to serialize access by some type of lock. (CRITICAL_SECTION works great)

Tim Smith

I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?

Jim Crafton12-Apr-02 8:03

12-Apr-02 8:03

would this result in crashes that seem to always result in an access violation in either the free() code ( it is deep in the MS heap allocator code) or new() ?

Tim Smith wrote:
Anytime you modify/read memory shared by multiple threads, you have to serialize access by some type of lock.
Yeah, I am doing this using mutexes there is a mutex for each list that I have (there are 3). Would CRITICAL_SECTION's be better ?