Announcement

**Simon Morgan** · 10 Nov 2008, 06:58 AM

It's not normally a good idea to store a dialog handle in a global, as you do (hDlg). There's too much chance of it not holding the handle of the dialog you think it does.

But in a callback function it is especially dangerous to use it (as you do in CBDlgProc). Use CBHNDL instead, if it's a DDT callback, to ensure that you are using the handle of the dialog invoking the callback.

That probably isn't the problem, though. Just an observation!

**Michael Mattias** · 10 Nov 2008, 09:14 AM

The following dialog is a small part of one of many DLLs recompiled by PB9 for my project.
..It seems that the sub cannot return to the control of the DLL

The DIALOG NEW for all those CALLBACK FUNCTIONs *is* in that DLL module, right?

(DDT requirement)

**Gösta H. Lovgren-2** · 10 Nov 2008, 10:05 AM

I hope someone of You might be able to see the bug at 'first sight'.

Norbert one thing that struck me is:

Code:

'----------------------------------------------------------------------------------
' CALLBACK DECLARATIONS
'----------------------------------------------------------------------------------
Declare CallBack Function CBDlgProc() [COLOR=red]' [B]AS LONG <<< Missing here[/B][/COLOR]
Declare CallBack Function CBDlgHelp()  [COLOR=red][B]'AS LONG <<< Missing here[/B][/COLOR]
Declare CallBack Function CBDlgSubClassTextbox() As Long

There is no AS LONG in the first 2 CallBack Function Declares, nor is there at the actual Function. I don't know if that has anything to do with it or not.

Another is that when Handles are assigned, they usually are assigned as DWORD, not LONG. At least in most code I see posted here by the experts. Probably not relevant either though.

The code is not compileable though, as the INCLUDEs are not included (not that I would expect them to be).

One other thought. It may be easier to get others to take a look at long stretches of code (like this is) if it were as an attachment rather than posted. The code window here is so narrow, long lines confuse the logic to the human eye (at least these old eyes). It's best viewed with an IDE editor. An attachment is easier (at least for me anyway) to load than C&P'ing long code.

======================================================
"I don't want to achieve immortality through my work;
I want to achieve immortality through not dying."
Woody Allen (1935-)
======================================================

**Michael Mattias** · 10 Nov 2008, 10:39 AM

Just a thought..

Code:

Control Send CbHndl, %ID_cboColor, %CB_GETCURSEL, 0, 0 To lRes
						If lres = 0 Then
							iFilterColorIndex = -1
						ElseIf lRes > 0 Then
							iFilterColorIndex = CInt(lRes - 1) 'Die Color-Liste startet mit "*Alle*" bei Index 0
						End If

It looks like you might be setting -1& to mean "no selection;" however, zero is a valid 'selected index' when using CONTROL SEND here.

'No selection' would be returned as CB_ERR (-1&).

MCM

**norbert doerre** · 10 Nov 2008, 11:31 AM

I have still to work on it....

Thank You all for Your comments.
It is not possible to attach the Includes, because only these few ones have about 12 MB of code. The code of this DLL is puzzled together from the content of similiar former code which has been tested since 1983 and which is causing no trouble. Whenever a lot of code has to be changed because of a new Programming language or because of a different OS, there reveals mostly no problem because You have to develop nearly from scratch. But as soon as only a small syntax change has to be done You have to pay attention, not because they are really hidden, but because You are too blind to see. The problem here is so severe because I cannot really leave out any line of code. Otherwise, the DLL would not give back any result, just like now. It might compile well, but won't run the way it should. When I compile it with PB8 under XP SP2, it runs fine, but not with PB9 and XP SP3. As soon as I will manage I'll attach here the correct syntax. Perhaps some others of You can share the correct syntax.

**norbert doerre** · 10 Nov 2008, 01:11 PM

@Michael

Michael, only to avoid misunderstatement:
Index 0 is a valid choice. Color numbers also start with index 0 = black.
But in most of these filter combos, there exists an item with index 0 which means "Don't mind" or "Don't use for filtering", hope You understand. So, index 0 of the box does not really correspond to color 0. Color 0 has index 1 in the box. No color would have index -1. But that's not possible in reality.
With "Don't mind" the user can leave a filter criterium unused.

**norbert doerre** · 10 Nov 2008, 04:31 PM

Cannot find the bug

As a first result I could find out that in fact only the BUTTON controls are causing that error, when they have a call attached at their end. All other much more complicated functions are working well as ever before.

Here once again some of the button definitions:

Control Add Button, hDlg, %ID_btnClear, "Neu", 612, 3, 20, 13, %BS_PUSHBUTTON Call ResetDialog()

Control Add ImgButton, hDlg, %ID_btnClose, "#" + Format$(%ID_ImgClose), 649, 3, 13, 13, %WS_CHILD Or %BS_PUSHBUTTON Or %BS_CENTER,%WS_EX_LEFT Or %WS_EX_LTRREADING Call CloseDialog()

When I write:
Control Add Button, hDlg, %ID_btnClear, "Neu", 612, 3, 20, 13, %BS_PUSHBUTTON '(w/o a call)
Nothing happens. No crash. Dialog remains stable.

As soon as there is a call attached at their end, the DLL crashes. It crashes even then, when the called function or sub consists of only two defining lines of code:

Function xyz() as long
End Function

In the following Sub, it crashes after the msgbox is correctly executed.

Sub xyz()
Msgbox "xyz"
End Sub

Isn't that strange?

-------------------------------------
By the way:

A "Dialog End" attached to any other function inside DlgSelFilter.inc ends the dialog correctly without a crash.

Perhaps somebody else has another idea???

**norbert doerre** · 10 Nov 2008, 05:16 PM

DLL crashing bug was found!

Well two kinds of callback functions were interfering each other:

a) CallBack Function DlgCallback() As Long

b) Control Add ImgButton, hDlg, %ID_btnClose, "#" + Format$(%ID_ImgClose), 649, 3, 13, 13, %WS_CHILD Or %BS_PUSHBUTTON Or %BS_CENTER,%WS_EX_LEFT Or %WS_EX_LTRREADING Call CloseDialog()

The definition of the Control Add function must not be added the Call CloseDialog() command as shown above.

Instead the latter must be added inside the Callback Function at a) like:

Code:

CallBack Function DlgCallback() As Long
'...
   Select Case CbMsg
		Case %WM_COMMAND
         Select Case CbCtl
            Case %ID_imgMatch	
            	iFilterEntityKind = -1
            	iFilterLayerIndex = -1
            	iFilterColorIndex = -1
            	iFilterLineTypeIndex = -1
            	iFilterLineWidthIndex = -1
            	fFilterLineWidthValue = -1
            	'UserTool und Prompt initialisieren
            	MCSetUserTool(1, "SelFilter", " Get Filter Parameters =>")
            Case %ID_btnByLayer
               '
               '  
               '
            Case %ID_btnClear
               ResetDialog()
            Case %ID_btnHelp
               FilterHelp()  
            Case %ID_btnClose
            	'Applikation beenden
             	Dialog End hDlg

That's all about syntax errors which are compiled with success, sometimes executed with success and sometimes with a crash.

**Cliff Nichols** · 10 Nov 2008, 10:04 PM

Norbert, I hate to say it but...I amongst others can not see the problem, unless you can replicate the problem

Most often just seeing, can solve the problem with a second pair of eyes on a minute point that is the cause, or even just prepping a submittable compilable code to demonstrate can cause a CNDS

I welcome it, I look for it, and I promise for it...but when it eludes me, and how much it eludes me...I SEARCH for it...and eventually 99% of the time I find it, but only with the help of others in the forums. (Sometimes WAYYYY off base, sometimes just 1 word tips me to the true cause of the problem) and almost EVERY time its something that I can not see without breaking down larger code to smaller code (Imagine that

)

Since we are all Pb'ers or at least "Programmers of sort" I know its hard to swallow, but sometimes "The user is right, and the programmer is wrong"

**Gösta H. Lovgren-2** · 10 Nov 2008, 11:02 PM

It appears to me that

Code:

         Case %ID_btnClose
                'Applikation beenden '<< [B]Dontcha just love it - gonna be in all me code after this {grin}[/B]
                 Dialog End hDlg '<<<[COLOR=red] Better to have DiaLog End [B]CbHndl[/B] (or so I've been told)[/COLOR]

has a conflict with something happening in Call CloseDialog() - SubClass of %ID_btnClose (maybe it's closing itself in there or something).

==================================
“If liberty means anything at all
it means the right to tell people
what they do not want to hear.”
George Orwell.
==================================

**norbert doerre** · 11 Nov 2008, 04:09 AM

Relicts of yesterday

Cliff and Gösta,
there exist in the mean time about 100 of similiar DLLs all built with the same scheme and never causing problems at least since the past 20 years. Only language updates and updated OS conditions made it necessary for some changes. I had to update the current DLL because with XP SP3 it's result became a windows exception. On my second machine with SP2 it is running well like ever. Well, I changed from PB8 to PB9 and from SP2 to SP3 nearly at the same time, not a good idea.
I always separate dialogs from other code, just to keep the best overview. So, I'm nearly able to add any dialog to any other code without conflicts. Using thes standard modules avoid many bugs und loss of time. But under some very rare conditions in fact problems are comming up, just like now. In the mean time I recompiled and tested all other DLLs with success. This faulty dialog sample here is one of the largest.

All the others use the scheme:

Code:

CallBack Function DlgCallback() As Long
   Select Case CbMsg
		Case %WM_COMMAND
         Select Case CbCtl

Normally, I never use direct calls within a dialog definition, because You quickly loose overview. And just this is what I could demonstrate here.

"Better to have Dialog End CbHndl":
Yes, certainly this is better style. But my code has it's roots dated in 1983 and even earlier, and programming language conditions changed a lot in the mean time. So there exist still anwanted relicts of yesterday, including myself. Some are reparable, some others not.

P.S.
Changing the current code from "hDlg" global to CbHndl did not correct the windows exception with XPSP3 and unchanged code. So I have to look a bit deeper with my love "IDA".

**Michael Mattias** · 11 Nov 2008, 08:40 AM

100 of similiar DLLs all built with the same scheme and never causing problems at least since the past 20 years

The PB/Windows compilers have not been around that long. Ergo your functions 'as written' have not been running without problems for twenty years.

"Similar" is just not good enough for debugging.

**norbert doerre** · 11 Nov 2008, 03:02 PM

@Michael

Michael, we are talking here about windows problems or problems with windows. I don't like windows and therefore it's part in my program is limited to perhaps two percent. My work has it's origin in unix, ran in the mid of the 70s with an Olivetti machine and was then transplanted first to dos, then windows and also linux. So, what we write about here is simply the changeable more or less ugly frame for a hopefully nice arranged picture.

**Michael Mattias** · 11 Nov 2008, 04:05 PM

> we are talking here about windows problems or problems with windows

That is but one possibility.

Announcement

Hard to find error in dialog

Hard to find error in dialog

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment