Combo's text part looses it's content after a tenth of a second

[norbert doerre]

I'm using a combobox which is dynamically filled with names. In the text part of it, i'd like to show the current programatically selected name with the following or similiar code:

ShowCombo(%ID_cboHatchName)
ComboBox Find Exact hDlg, %ID_cboHatchName, 1, sFilterHatchName To lRet
ComboBox Select hDlg, %ID_cboHatchName, lRet

The list index and the resulting name are always correct.
But the name only shows for a tenth of a second in the combo's text part; then it disappears again.

What could i do better?

[Michael Mattias]

Other then the BUG I found in COMBOBOX FIND EXACT, it works OK here

PB/Win 9.0.1

#COMPILE EXE
#DIM ALL

%ID_COMBO = 101
%ID_EDIT =  102


FUNCTION PBMAIN () AS LONG
    LOCAL hWnd AS LONG, I AS LONG
    
    LOCAL item() AS STRING
    
    REDIM item(25)
    
    FOR I = 0 TO 25
        Item(I) =  STRING$(6, CHR$(65 + I))
    NEXT
    
    DIALOG NEW  0, "Combobox Select Demo", 10,10, 300,300 TO hWnd
    CONTROL ADD COMBOBOX, hWnd, %ID_COMBO, item(), 5,5, 200,200
    CONTROL ADD TEXTBOX, hWnd, %ID_EDIT, "", 10, 250, 100, 14
    CONTROL ADD BUTTON, hWnd, %IDOK, "Look", 150, 250, 40, 15
    
    
    DIALOG SHOW MODAL hWnd CALL   CallBackProc
    

END FUNCTION

CALLBACK FUNCTION CallBackPRoc

  LOCAL S AS STRING, iPos AS LONG

   SELECT CASE AS LONG CB.MSG
       CASE %WM_COMMAND
         IF CB.CTL = %IDOK THEN

           CONTROL GET TEXT CB.HNDL, %ID_EDIT TO S
           IF LEN(S)  THEN
               'COMBOBOX FIND EXACT CB.HNDL, %ID_COMBO, -1&, S TO iPos ' <<< CAUSES PROGRAM TO ENTER ENDLESS LOOP
               COMBOBOX FIND EXACT CB.HNDL, %ID_COMBO, 1&, S TO iPos  ' 1 = start at beginning
               IF iPos THEN
                    MSGBOX USING$("Found '&' AT index #", S, iPos)
                    COMBOBOX SELECT CB.HNDL, %ID_COMBO, iPos
               ELSE
                   MSGBOX "Not Found"
               END IF
           ELSE
               MSGBOX "No Search Text"
               
           END IF
        END IF
   END SELECT
               
END FUNCTION

MCM

[norbert doerre]

a simple click

This is really mysterious.
The programmatical selection result is shown for a tenth of a second and disappears. But with a simple click into the text part of the combo, the selected item becomes visible. Function execution seems to be correct in my code.

[Nathan Maddox]

Do you have PB 9.0 instead of 9.01?

DDT in 9.0 may be calling LISTVIEW SET COLUMN with a negative 1 or 2
re: http://www.powerbasic.com/support/pb...ad.php?t=38856

[norbert doerre]

My PB Version is 9.01, and I just found the solution:

There exist 8 Combos one exactly over the other with different textual and graphical contents. Therefore, I have to start with showing the needed one.

ShowCombo(%ID_cboFontName)
ComboBox Find Exact hDlg, %ID_cboFontName, 1, sFilterFontName To lRet
ComboBox Select hDlg, %ID_cboFontName, lRet
Setfocus GetDlgItem(hDlg, %ID_cboFontName) ' <--- and that's it!

All the other combos are working normally, only those with text items loose focus after a programmatical selection. Just this is what I cannot explain.
After execution of "Setfocus GetDlgItem(hDlg, %ID_cboFontName)" the focus is regained and the selected item is visible in the text part of the combo box.

[Paul Squires]

Is your ShowCombo function simply bringing the desired combo to the top of the zorder, or is it also hiding the unwanted combos? You'll want to hide the unwanted combos and only show the one you're interested in. (you're probably already doing that).

[norbert doerre]

z-order handling

My program brings the desired combo only to the top of the zorder. There is nothing necessary to be hidden. The problem I have depends on the multiple MDI window structure of my program. User has to select an item in the graphical edit window, the selected item is evaluated in detail and it's parameters are distributed into some horizontally arranged graphical combos inside a tool bar appended below the menu area, to some text boxes and some check boxes. After a selection, the graphical edit area has the focus. The combos on top of each other at the left of the tool bar are shown depending from the kind of item currently selected.
The code is huge and mostly depending from also huge function libraries. So I'm not at all able to show a more evident example here.
I have to revise the z-order handling again.

[Michael Mattias]

Error 1 strikes again.

Oh well, at least a bug got found and reported, so that should get fixed in some upcoming maintenance release.

(You didn't get the error? Then you tested like PB support tested the first time, by only trying it with something which WAS in the list. IMNSHO not testing "not found" or "not a a valid entry" is "not testing.")

MCM

[Bob Zale]

Actually, Michael, the only bug here is in your source code. You entered a starting position of minus one (-1), when valid positions are one (+1) or greater. Results from the use of invalid parameters are undefined. You just need to be a little more careful with your coding and all will be fine.

In the interest of maximum execution speed and efficiency, PowerBASIC does not range-check or bounds-check parameters. That's made perfectly clear in the PowerBASIC documentation. Perhaps at some point in the future, in some sort of a "test-me" mode, you never know. We've given that some serious consideration, but there's been very little in the way of interest from those who are most important: PowerBASIC Customers. It would seem that most of our customers are pretty adept at writing correct code.

If you go on that TV show, and they offer you a choice of a prize in BOX1, or BOX2, or BOX3, which one would you choose? Would it be: "I want BOX number MINUS-1 ! !" ? Guess what your prize would be?

Best regards,

Bob Zale
PowerBASIC Inc.

[norbert doerre]

Fully functionable solution with multiple mdi windowing.

And this is a fully functionable solution with multiple mdi windowing:

'Programatically selecting an item in one of the combos, one over the other
lRet = MCGetSymbolName(iErr, szFixed)
sFilterSymbolName = Left$(szFixed, lRet) 'Ascii name of the symbol

If Len(sFilterSymbolName) > 0 Then   
  ShowCombo(%ID_cboSymName) 'see below
  ComboBox Find Exact hDlg, %ID_cboSymName, 1, sFilterSymbolName To lRet
  ComboBox Select hDlg, %ID_cboSymName, lRet
  '
  '
  '
End if


'-----------------------------------------------------------------------
' SUB ShowCombo (For a set of Combos one exactly over the other)
'-----------------------------------------------------------------------
Sub ShowCombo(ControlID As Long)
   'ControlID = ID of combo to be shown top most
   'Switching between n combos, one exactly over the other
   Select Case ControlID
      Case %ID_cboSymName
         Control Show State hDlg, %ID_cboSymName, %SW_SHOWNA
      Case %ID_cboFontName
         Control Show State hDlg, %ID_cboFontName, %SW_SHOWNA
      Case %ID_cboHatchName
         Control Show State hDlg, %ID_cboHatchName, %SW_SHOWNA
      Case %ID_cboObject
         Control Show State hDlg, %ID_cboObject, %SW_SHOWNA
      '
      '
      '
   End Select
 End Sub

[Paul Squires]

If you don't hide the unwanted combos then don't you run into the problem that your user could accidently TAB into a combo that you don't want them to? Once they do that then you'll have a problem.

Try the following simple to modify code:

'-----------------------------------------------------------------------
' SUB ShowCombo (For a set of Combos one exactly over the other)
'-----------------------------------------------------------------------
Sub ShowCombo( ByVal ControlID As Long )

   ' ControlID = ID of combo to be shown top most
   ' Switching between n combos, one exactly over the other
   ' Assumes that hDlg is a global variable
   
   Local nShowState As Long
   Local y          As Long
   
   ' Set the control ids to process
   Dim ComboIDs(1 To 4) As Long
   Array Assign ComboIDs() = %ID_cboSymName, %ID_cboFontName, %ID_cboHatchName, %ID_cboObject
   
   For y = 1 To UBound(ComboIDs)
      nShowState = IIF&( ControlID = ComboIDs(y), %SW_SHOWNA, %SW_HIDE)
      ShowWindow GetDlgItem(hDlg, ComboIDs(y)), nShowState
   Next

End Sub

[Michael Mattias]

As I told your support department, the compiler should NEVER generate code which results in the program entering "hang mode" because the COMBOBOX SELECT EXACT statement never returns.

Either a runtime error should be generated for the invalid starting row number and the statement should not be attempted, or the starting row should be adjusted when less than one to equal one.

MCM

[Bob Zale]

In that case, you would be very wrong. That's the approach taken by GW-BASIC, IBM's original BASIC-A, and some other legacy programming languages.

That's not the approach of PowerBASIC, nor for example, modern C compilers.

If you use PowerBASIC, you'll get the utmost performance most all of the time. We can't provide that performance by double-checking all your work for you (at RUN-TIME yet). That's why they call you a programmer. You write the code, we execute what you write.

Best regards,

Bob Zale
PowerBASIC Inc.

[Bob Zale]

Michael,

If you feel the need to have a little more "hand-holding" than PowerBASIC offers at this time, just write a little wrapper for each PowerBASIC function, which will verify the parameters and move on... You'll get what you want, and others will get the performance they want.

Best regards,

Bob Zale
PowerBASIC Inc.

[norbert doerre]

Ranking of controls

Paul,
my first thought was the same you write, hiding could be better, but it is tedious. Tabbing is not possible inside all my tool bars. This is simply a convention because cad dialogs can be quite complicated with lots of controls. So if you are not able to use a mouse or similiar then you will be frustrated after only five minutes of working with it. Try my simple solution with combo boxes all having the same size and one exactly above the other - that's important, because user must not klick accidently the frame of an unwanted combo.
I let it try out many hundred times and more under different conditions and never experienced an error. The advantage of my very simple code is that you need no more to administer the ranking of controls.

[Michael Mattias]

Consistency?

With #DEBUG ERROR on, a runtime error is set , the statement not attempted and the call returns.... eg your own example above re array bounds and null pointers... at which point the system ERR variable or other variables may be tested.

Even when #DEBUG ERROR is not on, the failing intrinsic statements RETURN (if no immediate protection fault).

And in the archtypal examples - trying to assign a negative value to an unsigned variable type or overflowing a loop counter increment - the statement returns and the "new" value can be tested.

But when an intrinsic statement does not return, the programmer has exactly zero chance to recover from an eminently trappable error.

That a user can code an infinite loop is one thing; that the compiler would generate one on its own quite another.

MCM

[Bob Zale]

The PowerBASIC compiler does not generate an infinite loop on its own. It executes the code you give it. This is entirely under your control. Just give it valid parameters, and you'll be fine. In this particular case, the failure to return is a Windows issue. Please feel free to report it to MS (for their fee of $195.00 USD) and you may find that they'll change the API so this doesn't occur.

The real point, though, is that it wouldn't make a lot of sense to change all the existing rules for just this one function. That would just give you a false sense of security. If we change this one, why not hundreds of other functions? It wouldn't be long before your EXE got noticeably larger and slower.

Best regards,

Bob Zale
PowerBASIC Inc.

p.s. Real men validate their own parameters

[Michael Mattias]

feel free to report it to MS (for their fee of $195.00 USD) and you may find that they'll change the API so this doesn't occur."

I went ahead and did a little additional testing and have discovered some things.

Both the DDT combobox ('CONTROL ADD COMBOBOX' + 'COMBOBOX FIND EXACT') and a standard Microsoft "combobox" class control ('CONTROL ADD "combobox"' + 'CONTROL SEND %CB_FINDSTRINGEXACT') exhibit the same bad behavior when the starting search index is out of the documented range.

Assuming the underlying technology of CONTROL ADD COMBOBOX and COMBOBOX FIND EXACT is the standard "combobox" class control and the CB_FINDSTRINGEXACT message, then "someone" may indeed have a reason to contact Microsoft.

I have expounded upon just who that might be in a separate email.

MCM

[Bob Zale]

Let's just see if I understand? You now want PowerBASIC to pay Microsoft to alter their API code? So that when you use it in an illegal fashion, with an illegal parameter, the results are changed to meet your specifications?

Let's just say I respectfully decline your kind invitation.

When you use the PowerBASIC ComboBox function with a valid, documented parameter, it works perfectly. When you use it with an invalid parameter, the results are undefined. Use of an invalid parameter is a programming error and we recommend you try your best to avoid it.

We once had a customer, Donald, who had a great problem using the MID$() function. It seems he could never remember whether the starting position parameter was based at zero or one. Over time, he became more and more difficult (livid). He finally demanded that we modify the compiler to pop up a MessageBox, in the running EXE, every time he used MID$(). He thought it should display the proposed return value and allow him to modify the parameter if it was needed. Donald had lots of ideas. I guess he thought it would help all PowerBASIC programmers (that means you) if this was automatic and mandatory.

Best regards,

Bob Zale
PowerBASIC Inc.

[Michael Mattias]

No need to bore everyone else with my thoughts... it's all in the email.

Let's just say 'COMBOBOX FIND EXACT' is not a Microsoft product.