Stuck again!!!

[Iain Johnstone]

This problem is wasting a lot of time and generating a lot of dubious language!
I have a window class registered as below, which is the same as all the window classes before it:

MENUNAME= "GRAFIXMENU"
'- Register the windows class
wndclass21.cbsize = SIZEOF(WndClass21)
wndclass21.style = %CS_HREDRAW OR %CS_VREDRAW
wndclass21.lpfnWndProc =CODEPTR(LinearProc)
wndclass21.cbClsExtra = 0
wndclass21.cbWndExtra = 0
wndclass21.hInstance = hInstance
wndclass21.hIcon =LoadIcon( hInstance, "APP")
wndclass21.hcursor = LoadCursor(%NULL, BYVAL %IDC_ARROW)
wndclass21.hbrbackground = gbrush2
wndclass21.lpszMenuName = VARPTR(MENUNAME)
wndclass21.lpszClassName = VARPTR( szClassName21)
wndclass21.hIconSm = LoadIcon(hInstance, "APP")
RegisterClassEx wndclass21

This is called by the following code:

CASE 423 ' linear schematic
GoToSleep gMain 'ignore
IF dongleon=1 AND go=0 THEN EXIT SELECT 'ignore
LoadData 'ignore

hLinear=CreateWindow (szClassName21, "Linear schematic",%WS_HSCROLL OR %WS_SYSMENU, 0, 0, 750,150,gMain,hMenu3, hInst,BYVAL %NULL)

MSGBOX szClassName21+crlf+STR$(hlinear)+crlf+STR$(gMain)+crlf+STR$(hMenu3)+crlf+STR$(hInst)+crlf+STR$(factor)

CenterWindow hLinear
ShowWindow hLinear, %SW_SHOWNORMAL
UpdateWindow hLinear


The message box displays various parameters.

This runs OK first time round, but having closed the window, it will not display again if CASE 423 is called - returns 0 in hLinear

The code associated with the window is:
FUNCTION LinearProc (BYVAL hWnd AS LONG, BYVAL wMsg AS LONG, BYVAL wParam AS LONG, BYVAL lParam AS LONG) EXPORT AS LONG

LOCAL NULL AS INTEGER
LOCAL lpPoint AS POINTAPI
LOCAL n AS INTEGER
LOCAL GraphText AS ASCIIZ*45
LOCAL q AS INTEGER
LOCAL redBrush AS LONG
LOCAL TotLength AS LONG
LOCAL CC1 AS INIT_COMMON_CONTROLSEX

SELECT CASE wMsg

CASE %WM_CREATE
CC1.dwSize=SIZEOF(CC1)
CC1.dwICC=%ICC_WIN95_CLASSES
InitCommonControlsEX CC1

FOR n=1 TO NoSects
IF LEFT$(drain(n),2)="1." THEN SysLength=SysLength+(length(n))
NEXT
factor=(syslength*0.2)-5

xMinScroll=1
xMaxScroll=100
xCurScroll=1
SetScrollRange hWnd ,%SB_HORZ, xMinScroll, xMaxScroll,%FALSE
SetScrollPos hWnd , %SB_HORZ, xCurScroll, %TRUE

CASE %WM_COMMAND
SELECT CASE LOWRD(wParam)
CASE 901
DestroyWindow hWnd
END SELECT

CASE %WM_HSCROLL
SELECT CASE LOWRD(wParam)

CASE %sb_lineleft
xNewpos=xCurScroll-1
SetXpos
CASE %sb_lineright
xNewpos=xCurScroll+1
SetXpos
CASE %sb_pageleft
xNewpos=xCurScroll-5
SetXpos
CASE %sb_pageright
xNewpos=xCurScroll+5
SetXpos
CASE %sb_thumbposition
xNewpos=HIWRD(wParam)
SetXpos
END SELECT

CASE %WM_PAINT
PaintLinear hWnd,xadjust

CASE %WM_DESTROY
FUNCTION =1
EXIT FUNCTION

CASE %WM_SYSCOMMAND


END SELECT

FUNCTION = DefWindowProc(hWnd, wMsg, wParam, lParam)

END FUNCTION

It is almost as if the window class was 'unregistered' when the above function is exited.

What have I done wrong? There is one other instance of this fault happening in the program, but all the other windows work OK. I am sure there is something simple that I have missed in the last 10 hours of cursing.

Any help gratefully accepted!
Iain Johnstone

Sorry about the line breaks - all single lines in original code.

------------------

[Scott Turchin]

Just a SWAG here (Silly WIld *** Guess), but this line:

IF dongleon=1 AND go=0 THEN EXIT SELECT 'ignore


Why not do an Exit Function, when the object/control/window has something occur it will re-enter the function..


I've seen the issue before but have not thoroughly examined your code yet..(at work)...


Scott

------------------
Scott
mailto:[email protected][email protected]</A>

[Iain Johnstone]

Scott:
This line is part of a 'dongle check' routine to see if the dongle has been removed whilst the program is running.
It does not affect the problem (sadly). I have removed the EXPORT from the function - silly mistake!

Keep the ideas coming please - the wife is beginning to pass unhelpful comments
Iain

------------------

[Peter Manders]

Iain,

Please check ERR and especially LastError after the call.

In a case like this, the first thing to check are your parameters.
For instance, you're using both hInstance and hInst, is that intentional or an error?
Maybe you are trying to create a window in another instance?

Do you have #DIM ALL and #REGISTER NONE at the top of your program?

This may be unrelated, but I've found that if Windows expects a pointer to a string, it doesn't like a NULL pointer. I've learned to supply an empty ASCIIZ string pointer instead.

I've also had trouble with constantly checking for a dongle. Try to disable the dongle check while debugging.

Just a few thoughts, I hope it's of some help.


Peter.


------------------

[Iain Johnstone]

Peter:
The problem is - it works perfectly first time round. The problem occurs when I try to run the function again. The values for hInst and hInstance are the same - I have already checked this one!
GetLastError return 0 every time, but the value for hLinear (the window handle) is always 0 after the first successful run.
I think the problem must be something to do with exiting from the proc, but this uses the same code as all the other 20 windows!
Iain

------------------

[Michael Mattias]

Maybe...

The way the SELECTS are nested,you are still calling DefWindowProc for hwnd even after you DestroyWindow hwnd.

Maybe after you DestroyWindow you should EXIT FUNCTION.

MCM

[Iain Johnstone]

Michael:
Already tried this - no effect. Totally baffled by this one - perhaps its time to call it a day on this and attack it tomorrow!
Iain

------------------

[Jules Marchildon]

Ian,

Send to me a compilable peice of code. I think I know whats wrong,
but I need some code to compile it to make the necessary changes.

mailto:[email protected][email protected]</A>

Regards, Jules

[Steve Hutchesson]

Iain,

I think the following code is incorrect, the WM_DESTROY message is sent
to the application AFTER the window has been destroyed, exiting the function
without performing the default processing leaves it in memory.

CASE %WM_DESTROY
FUNCTION =1
EXIT FUNCTION

If you need to do any processing on closure, try WM_CLOSE, thats where you
normally do things like test for exit, clean up etc..

Regards,

[email protected]


------------------

[Iain Johnstone]

Sadly a night's sleep has not improved anything in the brain dept!
Jules:
The compiled code for this prog is over 800K - it would be easier to send the lot with some guidelines rather than try to extract bits, because I ALWAYS forget something!

Steve:
I have tried various bits, and the code now looks like this:
FUNCTION LinearProc (BYVAL hWnd AS LONG, BYVAL wMsg AS LONG, BYVAL wParam AS LONG, BYVAL lParam AS LONG) AS LONG

LOCAL n AS INTEGER
LOCAL CC1 AS INIT_COMMON_CONTROLSEX

SELECT CASE wMsg

CASE %WM_CREATE
CC1.dwSize=SIZEOF(CC1)
CC1.dwICC=%ICC_WIN95_CLASSES
InitCommonControlsEX CC1

FOR n=1 TO NoSects
IF LEFT$(drain(n),2)="1." THEN SysLength=SysLength+(length(n))
NEXT
factor=(syslength*0.2)-5

xMinScroll=1
xMaxScroll=100
xCurScroll=1
SetScrollRange hWnd ,%SB_HORZ, xMinScroll, xMaxScroll,%FALSE
SetScrollPos hWnd , %SB_HORZ, xCurScroll, %TRUE

CASE %WM_COMMAND
SELECT CASE LOWRD(wParam)
CASE 901
destroyWindow hWnd
END SELECT

CASE %WM_HSCROLL
SELECT CASE LOWRD(wParam)

CASE %sb_lineleft
xNewpos=xCurScroll-1
SetXpos
CASE %sb_lineright
xNewpos=xCurScroll+1
SetXpos
CASE %sb_pageleft
xNewpos=xCurScroll-5
SetXpos
CASE %sb_pageright
xNewpos=xCurScroll+5
SetXpos
CASE %sb_thumbposition
xNewpos=HIWRD(wParam)
SetXpos
END SELECT

CASE %WM_PAINT
PaintLinear hWnd,xadjust

CASE %WM_DESTROY
FUNCTION = 0
EXIT FUNCTION


CASE %WM_SYSCOMMAND
SELECT CASE LOWRD(wParam)
CASE %sc_close
destroyWindow hWnd
FUNCTION = 0
EXIT FUNCTION
END SELECT
END SELECT

FUNCTION = DefWindowProc(hWnd, wMsg, wParam, lParam)

END FUNCTION


The error occurs at the CreatWindow (which it doesn't) in the calling section. The handle to the window is returned at zero.

Yours, baffled (because the routine works in other parts of the prog)
Iain

------------------

[Steve Hutchesson]

Iain,

Try commenting out

CASE %WM_DESTROY
FUNCTION = 0
EXIT FUNCTION

for the moment, you are not processing anything there so see what it does,
I suspect that the problem you are having is that the window is still in
memory after it is closed.

Try closing the window with the following line,

SendMessage hWnd,%WM_SYSCOMMAND,%SC_CLOSE,ByVal %NULL

and see if you can restart the window again.


Regards,

[email protected]bq.com.au

------------------

[Iain Johnstone]

Hutch:
Thanks for the suggestion, but sadly no go. The window is destroyed and will not reappear. Does the handle to the window get set to zero when it is destroyed, or does it rtetain the original value.

The really annoying bit is that I copied this procedure from another that works OK in the same program, and changed a few items to suit the new function. The basic code is identical to other working procedures. What I have not stated is that there are 22 windows registered in this program - have I reached an unknown limit somewhere along the line? The two windows that show this problem are the last two registered.
Iain

------------------

[Steve Hutchesson]

Iain,

I just tested a small demo program I have here that creates child
windows and it comfortably created 60 windows with no problems so
I don't think the problem is related to a window count limit.

The created windows that I tested all started as a seperate
instance and all use the same message handling proc so the problem
you are having must stem from elsewhere.

Regards,

[email protected]


------------------

[Lance Edmonds]

Iain, are you sure the O/S is not running out of (GDI) resources? With such a large app, memory usage could be huge...

Install Resource Meter (or an equivalent app for your O/S) and leave it running while your app runs. Under Win2k, you can use Task Manager for this purpose.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Iain Johnstone]

OK - panic over! I am not sure exactly what the problem was, but reloading the menu before creating any subsequent windows has solved the problem. I do not understand this, as there is nothing that will affect the menu in any following code. However, this is academic, as it works now! Apologies and thanks to those who spent time and effort on this on my behalf - I just wish that I could make a positive contribution sometimes instead of always being on the asking end.

Lance:
This is a big app! - it took 2.5Mb to send the code and DLLs to Jules - I hope he is not still downloading it.

Iain

------------------

[Jules Marchildon]

Iain,

I just discovered it as well. You have loaded up the hMenu3(menu) and
when you created the window class you assigned it to the wndclass21.lpszMenuName
member. So any calls to Createwindow() do not require you to pass the hMenu3 handle.
In your case the first Createwindow() call you included the hMenu3 handle,
so after you destroyed the window the menu was vaporized and the next calls
would fail.

Anyway, played with your Demo, Very Nice application!

Regards, Jules