[Not Bug] FindString find not the string

[Kwai chang caine]

Hello

Is it normal ??

Code: Select all

Debug FindString("a", "A", #PB_String_NoCase)

Result 0

I have try v5.22 and 5.30 it's the same thing
If i remove #PB_String_NoCase that's works

Good day

[majikeyric]

Hey KCC,
you have forgotten one parameter (the start position).

Code: Select all

Debug FindString("a", "A",1, #PB_String_NoCase)

[Kwai chang caine]

Aaaaarrrrrggghhh !!!!
It's not the first time

FREEEEED !!!! Please ....a protection, is really wellcome

Thanks a lot MAJIKEYRIC

Have a very good day

[blueb]

I still think there's something wrong....

The help file states: ' If this parameter isn't specified, the whole string is searched. '

KCC's results show that this is not the case.

[Tenaja]

I ran into this myself just last week. (Fortunately I sorted it out within a few minutes.)

The bug is that you are using a string as an argument for an Int, and the compiler is not throwing an error.

[c4s]

The help file states: ' If this parameter isn't specified, the whole string is searched. '

KCC's results show that this is not the case.

Well, in KCC's case #PB_String_NoCase (= 1) is the start position. The parameter "isn't specified" if something like FindString("a","a") is used.

[netmaestro]

This crops up every so often with different commands, if you specify an optional parameter that appears later in the list, all other optional params that appear before it have to be specified too. Personally, I'd like to see Fred make this syntax legal:

Code: Select all

Debug FindString("a","A",,#PB_String_NoCase)

instructing the command to use the default for the first optional parameter while specifying the second. This way the coder doesn't have to read up on all the optional parameters and supply values for them. Who likes reading documentation anyway? Ick.

[davido]

@netmaestro,
+1
Thanks, perhaps you will be heard.

[Fred]

While I understand the optional proposal, how would it help in this case ?

May be a solution would be to change the constant values to negative one, so we could introduce a runtime debugger check to check this.

[wilbert]

May be a solution would be to change the constant values to negative one, so we could introduce a runtime debugger check to check this.

I doubt if that will solve anything. If you take PeekS for example

PeekS(*MemoryBuffer [, Length [, Format]])

Length can both be positive or negative (-1).
So if you accidentally forget to specify Length and only specify Format, sign checking won't work.

[PB]

This command doesn't really need fixing; it was just user error.

But if anything: maybe swap the start position and mode flags,
because that way KCC wouldn't have had any error, and the
starting position is likely always going to be 1 in most cases
anyway, which means it should be optional? I don't know.

[Thade]

+10 PB

But if anything: maybe swap the start position and mode flags

Yes and not only in this case ... no special function ready at present ... but I often think, why is this Parameter at the end of 3 optional parameters, when it is the most important and has to be the first while the other parameters are not touched anyway ... you often have to look up what the default parameters are to fill them in, when you only need the last one changed.

[skywalk]

Changing the order of parameters breaks lots of code.
I prefer the blank optional parameters request similar to netmaestro.

[Thade]

Changing the order of parameters breaks lots of code.
I prefer the blank optional parameters request similar to netmaestro.

True and an important aspect.
The other idea (sort options by importance) is therefore better kept in mind when developing new functions.

[Foz]

Just as a thought, but what if it was possible to say, all functions *have* to define all parameters, i.e. EnableExplicitParameters.

Personally I detest optional parameters, because (imho) it encourages bad coding practice, such as the same function doing completely different things, depending on the parameters and *how many parameters* I pass in!

Instead of spending more time up front, creating more functions that describe what that function actually does, and changing the appropriate places, it's covered over with quick and dirty programming, which then comes back to bite you on the backside when a function does something unexpected, or even worse, when the parameters have to change.

And yes, I have been bitten by this problem more times than I care to regale.