[win32] the most bizarr error ever..

Started by
16 comments, last by taz0010 13 years, 5 months ago
Im creating this TimerLog class, that calculates frame durations and outputs to file, Im just using the win32 api..

Until now it was working just fine, it do everything ok, I was testing it before the message loop, it was "donne".
Now I just tryied to create one at the windows procedure, and my application first started to "get dead"(it stills was doing stuff cause I have hard coded it to display fps, and it was indeed being displayed)), it didnt receive any inputs..

I got those debug outputs saying stack overflow( O.o how can that be, it didnt do anything), and 4 other saying writing acces violation...I cant get it anymore cause all of sudden it changed behavior o.O

Now I get an error creating the main window..guess what is the error? errorcode == 0( ERROR_SUCCESS )..very informative..

Trying to isolate the problem, the only thing I could figure out is that the CreateWindowEx function is not getting at the windowprocedure(it should)..

The problem is for sure with that class at the window procedure, since if I comment it at the wndproc it backs to normal...but I cant see any connection(this class just appears at a very specific WM_COMMAND, it just get theres if user press a specific menu button..)

I dont know what piece of code I could post here..Notting is making sense to me..any ideas?
Advertisement
When CreateWindow() or CreateWindowEx() is called, it sends a few messages to the window that it creates. If it doesn't like the responses it gets back, it cancels the window creation and ERROR_SUCCESS will be the result. Example: if the window procedure returns FALSE when processing WM_NCCREATE.
It never gets at the window procedure, the break point isnt reached..
When it works, createwindow jump execution to windproc, since Im not handling wm_create it gets at the DefWindowProc..

I found out what causes the problem, but I still dont know why, it still doesnt make sense to me..

If I call the constructor without parameters it works fine..

I have just one constructor, that takes 3 parameters, all 3 parameters have default values( it makes it my default constructor?):
TimerLog(	const CHAR* szFilename_p = NULL, DOUBLE TimeInterval_MSec = 1000.0,				TIMING_DESIGN eDateOrder = eDAY_MONTH_YEAR_HMS );


So..it just works if I call the constructor with its default parameters values( means without parameters)..
I tried removing default values from the prototype and:
--calling with my own parameters - SAME ERROR
--calling default constructor - WORKS(but I dont have a default constructor..I cant use the class like this)

Still weird, I have other classes at windproc that works fine with its explicits constructors(and they dont have a default constructor defined also), why it doesnt accept my constructor?



Any ideas?I still dont have a clue..
I started to think it could be the size of windproc, but commenting out lots of stuff there still doesnt solve..

The behavior changed again, it doesnt crash, its like not receiving input again, with a minor difference that now I can see the menu buttons highlighted when the mouse is over(but they highlighted with a one color blue..not the windows default way..

Thats freaking weird.
1: You need to debug your code and find out why this is happening.
Calling a normal C++ class constructor has nothing to do with a window procedure or CreateWindow - there must be some interaction there, what is it?

2: This is an advertisement for source control, if you can compare your changes against the last version that worked, you know where the problem is.

As I said, if I cut out the class from windowsproc, it works man, I KNOW it doesnt make any sense, but jeezes, it works fine outside the windows proc..Thats the most important track of changes..it have to be something with that class..But how can that generates problem..just at the windows creation..without the code reaching the class...

Just think on that, removing that from windproc make it backs to normal..

The constructor is just called(inside the windows proc) if the user clicks the rigging button at the menubar, and if a file is succefully opened..this never happens cause the insane behavior starts as soon as the window is created.

I hope its a stupid error, but this behavior is tottaly nuts..its like some compile error just being detected after runtime..

I tried having a default constructor and a init function, same problem..
Can you show us your code? Perhaps the whole window procedure?
My window procedure :

line 569

line 4079

-__-..my app is like a multifunctional based on its menu buttons..

I will resume it here:
static LRESULT CALLBACK WndProc( HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam ){	static BOOL bHullSetPointsFromInput = 0;	static Vector3 *pPoints = NULL;	switch( Msg ){		case WM_COMMAND:			switch( LOWORD( wParam ) ){				case 2000:{}break;				...			}			return 0;		default:			return DefWindowProc( hWnd, Msg, wParam, lParam );	}}

I dont think it helps, here a screenshot:
http://i16.photobucket.com/albums/b29/0o--Karnage--o0/wndproc1.png

at case 4000 I have the class object:
case 4000:{//Rigging/Open
				case 4000:{//Rigging/Open					//NOTEs:					//-for using the fbx sdk, the include directorie at the sdk path is setted					//on the project properties(C++ additional include diretories)					//-the lib directories also(linker additional lib dir)					//NOTE:files supported:					//autocad .dxf/Collada .dae/3D studio .3ds/alias .obj					//Open Dialog Stuff:					OPENFILENAME openFile = {0};					openFile.lStructSize = sizeof(OPENFILENAME);					openFile.hwndOwner = hWnd;						TCHAR szFilters[] = { TEXT("Autodesk FBX file\0*.FBX\0COLLADA\0*.DAE\0Obj\0*.OBJ\0\0") };					openFile.lpstrFilter = szFilters;						TCHAR szFileName[256] = { TEXT("\0") };					openFile.lpstrFile = szFileName;					openFile.nMaxFile = 256;						TCHAR szFileTitle[256] = { TEXT("\0") };					openFile.lpstrFileTitle = szFileTitle;					openFile.nMaxFileTitle = 256;					openFile.lpstrInitialDir = szRiggDir;						DWORD dwOpenFlags = OFN_DONTADDTORECENT|OFN_FILEMUSTEXIST|OFN_HIDEREADONLY|OFN_NONETWORKBUTTON;					openFile.Flags =  dwOpenFlags;						TCHAR szExt[] = { TEXT("fbx") };					openFile.lpstrDefExt = szExt;					if( GetOpenFileName( &openFile ) ){						...						//timing data:-----------------------						timerlogger::TimerLog my( "myfile", 1000.0, timerlogger::eDAY_MONTH_YEAR_HMS );						FLOAT sec = 0.0f;//msec = 0.0f;						//----------------------------------

Simply commenting out the line timerlogger::... everything is ok..

If u have windows 7 you know that menus should look like this:
http://i16.photobucket.com/albums/b29/0o--Karnage--o0/particleNormalBlend.png

See the highlighted button? When my app go nuts, it looks like this:
http://i16.photobucket.com/albums/b29/0o--Karnage--o0/goingcrazy.png

None of the buttons works..with means it never reaches case 4000...
If I put a breakpoint in the windowsproc, it doesnt break, but the message loop stills loops..

I uploaded the .h and .cpp of the timerlog class on google docs, first time Im using it, dont know if everything is fine:
https://docs.google.com/leaf?id=0B_iN9pcbyoiKNDk2ZjhhZjAtOTFjYS00Yzg0LWE1MDItN2Y5YzQ2YzMxNzI2&hl=en&authkey=CKjzkaYB


https://docs.google.com/leaf?id=0B_iN9pcbyoiKYjUyZTVmMTItYTY1My00NDE1LTgwYTYtZDc4ZWY1N2I0YzVk&hl=en&authkey=CLnCw6gF

>_< I bet its a stupid thing..

It have to be a crazy bug..I created a function that the only thing it do is calling the timerlog constructor:
void Foo(){
timerlogger::TimerLog myLog( "myfiletest", 1000.0, timerlogger::eDAY_MONTH_YEAR_HMS );
}

I replaced it on the windows procedure, it compiles and runs fine, so I put a breakpoint in the function call, when the code get there, I press f11 to enter the function..nothing happens..absolute notting happens, the yellow arrow disappear, it doesnt get at the function, so I press f10 and it continues like nothing happens..My vs is on crack..why things like this happens with me.. T_T Im depressive
Is it possible your TimerLog function is throwing an exception? There's actually bug in Windows 7 where exceptions thrown inside a message loop are automatically caught.

http://support.microsoft.com/kb/976038

Try putting try/catch blocks around the function call and see if they catch anything

This topic is closed to new replies.

Advertisement