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

[Bob Zale]

Actually, I believe I am suggesting the compiler generate code to trap invalid parameters at runtime.

Which, frankly, does not seem all that unreasonable to me.

MCM

I see you edited this message after my last reply. So, I'll respond to this comment, too.

No, it's not unreasonable to validate parameters... It's simply a matter of choice. Faster/Smaller or Validate. Our philosophy has always been the first, and our customers generally seem to approve. As I mentioned earlier in this thread:

"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."

This idea has possibilities, if our customers want it sufficiently. We'll see...{smile}

Best regards,

Bob Zale
PowerBASIC Inc.

[Bob Zale]

Actually, I believe I am suggesting the compiler generate code to trap invalid parameters at runtime.

We have a very nice mechanism in place for just that purpose. Back about 300 or 400 messages ago (post #21), I offered a very nice suggestion to you:

If you have a suggestion of how any PowerBASIC feature can be improved, we invite you to submit them to [email protected]

We consider every suggestion very carefully, but particularly any that are requested by many customers. In this case, customers must choose between FASTER/SMALLER CODE or VALIDATED PARAMETERS. So far, the first is a big winner. Incidentally, repeated demands by one person doesn't add much to the mix. We actually consider that a subtle form of cross-posting.

Best regards,

Bob Zale
PowerBASIC Inc.

[Bob Zale]

Yes, it is excellent compiler-creation style. We have been following this philosophy for many years on all versions of our Windows compilers. Quite successfully, thank you.

Have you ever considered creating your own compiler? Then you could add all the time-wasting, bloat-filling code you want. Considering all the time spent by everyone over such a superfluous issue, you could probably be half done by now.

Best regards,

Bob Zale
PowerBASIC Inc.

[Michael Mattias]

What you are suggesting is that programmer errors be corrected at run-time. Is that really good programming style?

Actually, I believe I am suggesting the compiler generate code to trap invalid parameters at runtime.

Which, frankly, does not seem all that unreasonable to me.

MCM

[Bob Zale]

>It works precisely as advertised.
Except the documentation forgets to advertise what happens when search index is out of legal range.

I'm afraid that's not correct, either. We didn't "forget", this was intentional. PowerBASIC does not document what will happen in each and every possible situation where you choose to break the published rules. Even if we tried, our 700+ page printed manual would be 2000 pages, double the price, and it still wouldn't be complete. If you use an illegal parameter in PowerBASIC, the result is undefined. We recommend against that tactic.

I have sent a documentation improvement suggestion. (Which suggestion has exactly zero chance of appearing "as submitted").

Since you know it has zero chance, why would you do that? Do you really want to delay our engineer's response to a customer with a real question? A real request for help? I really don't understand this.

re COMBOBOX FIND EXACT... not currently shown in doc and should be : "If an invalid starting search index value is supplied, the results are undefined, except if it is negative when cast as a long integer (that is in the range 0x80000000 to 0xFFFFFFFF) , your program will enter an endless loop, requiring you to terminate the process using Task Manager or other tool."

I will agree this has zero chance, because it's clearly flawed. Even if we really wanted to waste all those printed pages, the words aren't necessarily true. How do you know it's a loop? And how do you know it's endless? Have you tested it on every version of Windows? Every service pack? Numerous Intel and AMD cpu's? We haven't either, because results from illegal parameters are simply undefined. That means "Don't Do It".

An invalid parameter like this is a programmer error. Pure and simple programmer error. It needs to be corrected before compilation, not at run-time when speed is always critical. You suggested that we generate an error, so you could set up an error trap, wait for the exception to occur, then correct it and re-try the operation. Did you give that any thought at all? It makes no sense. If you could write an error handler to correct the problem, it's clear you already know the necessary parameter value. So just fix it before you compile! And save all that run-time bloat and your wasted programming time, too.

What you are suggesting is that programmer errors be corrected at run-time. Is that really good programming style?

Best regards,

Bob Zale

[Michael Mattias]

>It works precisely as advertised.

Except the documentation forgets to advertise what happens when search index is out of legal range.

I have sent a documentation improvement suggestion. (Which suggestion has exactly zero chance of appearing "as submitted").


MCM

[Bob Zale]

Wonderful, Michael ! You are absolutely correct.

COMBOBOX FIND EXACT is a product of PowerBASIC, so PowerBASIC defines the way it works. It works precisely as advertised. I'm sorry that you do not seem to like the way it is advertised, but it's clear that we cannot possibly please every user over thousands of combinations of statements and functions. There will always be some differences of opinion.

If you have a suggestion of how any PowerBASIC feature can be improved, we invite you to submit them to [email protected]

Best regards,

Bob Zale

[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.

[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]

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]

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]

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

[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.

[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.

[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.

[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

[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

[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

[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.

[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