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

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

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

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

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]

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.

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

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.