Bxn
(Getting the hang of it)
2002-06-06 05:08 PM
Instr() Behaviour

As I discussed with some Members in the Suggestions Forum, I'd like to report something which puzzle me for a long time :

The following script :

$String1 = "ABCD"
$String2 = "A"
$String3 = ""
? Instr($String1,$String2)
? Instr($String1,$String3)

returns :

1
1

I sure understand the mathematical point of view that argues "Empty is in Everything", but I would have preferred a returned value of -1 for eg., or 0.

Am I Wrong ?


Richard H.Administrator
(KiX Supporter)
2002-06-06 05:11 PM
Re: Instr() Behaviour

Original thread here.

{EDIT}
Oops - fixed link.
{/EDIT}

[ 10 June 2002, 10:03: Message edited by: Richard Howarth ]


LonkeroAdministrator
(KiX Master Guru)
2002-06-08 04:17 AM
Re: Instr() Behaviour

cant get to the original thread...

I quess, for logical point of view it should be as it is.


Les
(KiX Master)
2002-06-08 04:21 AM
Re: Instr() Behaviour

Howard,
you managed to get an extra http:// in front of the link.

The correct link should be http://81.17.37.55/board/ultimatebb.php?ubb=get_topic;f=4;t=000222


LonkeroAdministrator
(KiX Master Guru)
2002-06-08 04:35 AM
Re: Instr() Behaviour

thanks les.
didn't bother to check it.

but now when I've red it I can say this ain't bug.

and about giving empty value...
if it is a control char and also the string to be check on, it should return correctly: "Match"
but if user puts something dynamically in to this string comparison and does not make any length check or error check, it is he himself who gets the blame.

so what ppl where really talking about was that when instr() does not have
if len() fail endif structure inbuild
it is a bug!

this is really weird thinging.
missing a feature is not a bug.
as a user of various m$ products, I can say it's vice versa.


Les
(KiX Master)
2002-06-08 04:48 AM
Re: Instr() Behaviour

I guess I'll have to toss in my 2 cents (CDN). Without getting into a zen debate... it is a bit of a paradox. True, if you search for nothing, you find nothing, hence the positive return but...
the positive return is the offset which is incorrect.

So, I believe it should not return a 1 but rather it should return a 0.


LonkeroAdministrator
(KiX Master Guru)
2002-06-08 05:39 PM
Re: Instr() Behaviour

les, you are correct... somehow as it's thinked.

but, if you think of the string.
it start counting from 1
does the first char match.
with nothing everychar matches.
so. it gives the first occurance in string.
it is the current coding.

to fix it to zero in way that it checks first for char 0 which (obviously) is nothing.

but the returning value 0.
doesn't that inform that there is no string present in presence of another?

this is actually little bit tricky and even thou it isn't a bug, it might get newbies to not to use it.
but has it over the years?
it has been working for long time and like the way it is.


Bxn
(Getting the hang of it)
2002-06-10 09:59 AM
Re: Instr() Behaviour

Very Disapointed about these views, Lonkero ...
First of all my poor english probably prevented me to fully understand the very substance of your first post ... (20020608 04:35), but I guess it's largely discussing about the duty of a programmer to check the values of variables used in order to prevent a lot of confusing things. If it is so, I of course agree with that ... Be sure I check the numeric variable $X before evaluatin' 1/$X !
Concerning the second post, I think, you certainly noticed that in my first post, I suggested too that "nothing was in everything". Well, but I don't agree with your statement "with nothing everychar matches".
the term "matches" is to vague to be USEFUL in a programming language (Thanx to Richard Howarth to have remind me this premacy of 'useful' coding against 'beauty of mathematical concepts' ! [Wink] ).
I realized that if I accept an Empty String matches a "A", tomorrow, one programming language developper will furbish me with the super tricky function SuperTrickyGraphicalInstr(), which will return 1 when I evaluate SuperTrickyGraphicalInstr(";","."), just simply it found a dot in ";".
Unless very much documented, a fine and consistent function should only evaluate Strict Identity, not 'belonging'.
You also state "it start counting from 1", unless you are the developper of KiXtart, that's only one point of view.
I personnally have to suggest would someone want to reflect the "theorical fact" that empty is in everything, in my example with string "ABCD", it should check the empty space before the A and shout : "Match !" and return 0 (suggested also and again by Richard Howarth).

In terms of consistency, reliability and efficiency, you didn't convince me, but did you ever tried ?

Nevertheless, this debate could be opened for other programming languages (or self proclammed Prog. Lang. !) :
I have tried equivalent functions with Turbo Pascal 7 [Pos() function] and MS Excel [localized Cherche() function] ...
With my example, the first returns 0, the second returns 1 ...


Jack Lothian
(MM club member)
2002-06-10 09:28 PM
Re: Instr() Behaviour

My 2 cents worth.

I think you guys are mixing two subject: usefulnees of the function & proper logic.

Logically if you search for nothing you will find what you are searching for. Furthermore since you found something it must be somewhere. Logically it was in the first place you looked. Logically I think the function is consistent. Consider the point if you search for a null string in a null string. They are equivalent in every sense and if you follow some of the logic given above you wouldn't find one in the other. Isn't this illogical.

(I am not sure but might this not be a variant of the Bertand Russell paradox concerning set theory. The implication of the theorem is some logic systems are not closed.)

But consistency is not everything, since multiple consistent logic system can be constructed. I think the thrust of Richard's comments is that in this case usefulness might be a better criteria than logic. I tend to agree with Richard.

[ 10 June 2002, 22:27: Message edited by: JackLothian ]


Jack Lothian
(MM club member)
2002-06-10 10:24 PM
Re: Instr() Behaviour

[Embarrassed] Oops

Bxn
(Getting the hang of it)
2002-06-10 10:52 PM
Re: Instr() Behaviour

Dear Jack,

That's in substance what I said.

But you see it obviously lead to some debate among developpers.

Nevertheless, if you agree our PoV (or Howard's) you can't say the function is really consistent as provided.

You said :

"Logically if you search for nothing you will find what you are searching for."

Uh oh ! That was the meanin' of my first post : "Nothing is in Everything". But we are programmers, we don't "search for nothing", we search for the "null string" and as far as I know in a programming language the Null String is not 'nothing', it's not the 'no code' character.

As a programmer, I don't expect from a function to answer :
"Oh you lazy boy, you're lookin' for nothin' so here's my answer : you win, and first try !"
where first try would lead me to "A" or "Z" ...

"Furthermore since you found something it must be somewhere. Logically it was in the first place you looked. Logically I think the function is consistent."

I already have heard this (Hey Lonkero !) ... But why should the first place we look, be the number "1" ? Especially concerning the Null String, the first place we have to look, is before the first char., where there's nothing as we all agree ... Returnin' "1" is not consistent. "1" is the position of the "A", and even if we all agree the element "nothing" is in every set, I've never been told that the element "nothing" was in all element of the set ! That's, I think another common confusion.

"Consider the point if you search for a null string in a null string"
Yes, there is strict identity between these values, but what's the lenghth of the null string ? Would it really have sense to return "1" where length is "0" ?
So, I would like a returned value of -2.

"But consistency is not everything," sure, that's why I like Neural Networks so much.

"I think the thrust of Howard's comments is that in this case usefulness might be a better criteria than logic. I tend to agree with Howard"

So Do I, But His Rate Is Already At Max. [Big Grin]


Bxn
(Getting the hang of it)
2002-06-12 12:55 AM
Re: Instr() Behaviour

And if we read (again !) the Doc Page 19, we see :
"Scripts can contain any character, except the /0 (NULL) ..."
So ...


LonkeroAdministrator
(KiX Master Guru)
2002-06-11 02:22 PM
Re: Instr() Behaviour

bxn...
is 0 length string same as if it contains null?
NOT.
it also depends of the language, but in many cases the null char needs to be added.

this is just for nothing, cause I tend to agree with howard too, but like the "moral"/"political" issue in this thread [Smile]


Bxn
(Getting the hang of it)
2002-06-11 02:47 PM
Re: Instr() Behaviour

Lonkero,
You're right, I certainly go too far in this case ! [Wink]
And I think you're right too when noticing it's language dependent !

And Finally, I'm glad to see your PoV more accurately ...
[Smile]


Richard H.Administrator
(KiX Supporter)
2002-06-11 03:26 PM
Re: Instr() Behaviour

Lonkero,
quote:
is 0 length string same as if it contains null?
NOT.

Well, to be pedantic yes it is. The null character Chr(0) terminates a string. Therefore a string is actually all the character you can see, plus a Chr(0) at the end that you can't.

The string "Hi!" is actually four characters long -
'H' 'i' '!' '\0'

The empty string "" is 1 character long -
'\0'

This is the core reason why you cannot easily manipulate binary data as strings.


Bxn
(Getting the hang of it)
2002-06-11 04:31 PM
Re: Instr() Behaviour

That's what I'd learned from other languages, but after the affirmation of Lonkero, I was not sure KiXtart did the same ...
Glad to learn more and more !


LonkeroAdministrator
(KiX Master Guru)
2002-06-11 06:08 PM
Re: Instr() Behaviour

howard... yes. yes.
I can see it being that way in C/c++
but, it's not as it's have to be that way.

kix, as it's script-language, can determine pretty much what strings contain.

and if you try to add to the end of string manually the null character what happens?
cause that's allowed in c...

so I'm speaking, like this thread, theoretically, as ruud hasn't said (uttleast to my knowledge) what elements string contains other than viewable characters if any...


BrianTX
(Korg Regular)
2002-06-11 08:59 PM
Re: Instr() Behaviour

This is a GREAT discussion!

I find myself more and more in agreement with the idea that:

SUBSTR($X,"") should always return 0.

As was mentioned before, the value returned is an index of the first instance of the 2nd string passed to the function. Even if using set theory causes us to say that the null set is in anything, the value indexed as 1 can never be equal to an empty string.

Brian


LonkeroAdministrator
(KiX Master Guru)
2002-06-11 09:04 PM
Re: Instr() Behaviour

yeah.
but zero neither is correct one.
it should error out or give negative value.

but when starts all things work theoretically work correctly in practise?


BrianTX
(Korg Regular)
2002-06-11 09:05 PM
Re: Instr() Behaviour

How is zero incorrect? If the 2nd string (not empty) is not in the 1st string, then there is no index, either, so zero is returned. This would be exactly the same situation. Are you saying that if a string doesn't exist in the other string, we should assign that a negative value as well?

Brian


LonkeroAdministrator
(KiX Master Guru)
2002-06-11 09:32 PM
Re: Instr() Behaviour

no.
all I'm saying is that having it at position before first character is different from having no match at all.
but...
as I put my mind to rest I come more close to others opinion.
and the arguments I said about string having something inside and kix can make it's ways.
so, I think I'll give up. when matching against zero length string it should return 0 as no match.
matching viewable characters not possible other parts string may contain.


Bxn
(Getting the hang of it)
2002-06-11 11:52 PM
Re: Instr() Behaviour

Hi, Brian ...
You asked :
quote:
Are you saying that if a string doesn't exist in the other string, we should assign that a negative value as well?
Well, not exactly, if Lonkero permits me to take the service [Wink] ...

Of course if a string is simply not present in another string, no use to return another value than zero, as the documentation states.
But, the problem in our case is that we can't really prevent some people (and me, Oh God For One ! I was [Wink] ) to hammering the null string is present in every string and HowEver not to be satisfied at all with a return value of 1 as it actually is.

The special case of the empty string :

It is PRESENT, but DIFFERENT FROM EACH (every ?) CHARACTER in the string ... Sure you Follow me ...

So :

Present => return value <> 0 (>0 accordin' to the doc.)
Diff. From Each Character => return value = 0

That's why a returned value < 0 wouldn't have been illogical to my mind.

But, although I initiated the topic in that way, I would now perfectly agree with the fact, that it wouldn't be very efficient and certainly would have a malicious effect in some existing code ...

'Hope to be boring ...


Bxn
(Getting the hang of it)
2002-06-11 11:54 PM
Re: Instr() Behaviour

Sorry, lapsus :

'Hope NOT to be boring [Wink]


Richard H.Administrator
(KiX Supporter)
2002-06-12 09:42 AM
Re: Instr() Behaviour

Lonkero,

First, *please* stop calling me Howard. It gets awfully confusing and I don't think Howard should take the blame for my views and mistakes [Wink]

To pick up on a couple of your points:
quote:
kix, as it's script-language, can determine pretty much what strings contain
Don't forget that KiXtart is an interpreted language. There is a program which is reading the code and translating it. That program is written in...?

Ultimately the way strings are handled is determined by the interpreter. Strings are almost always handled as zero terminated arrays of characters. As in other languages, if you want to handle binary/raw data you don't use strings to do it, you use a binary storage object.

quote:
and if you try to add to the end of string manually the null character what happens?
cause that's allowed in c...

No it's not allowed in C.

If you treat the object as a string you cannot add '\0', because that's the end of the string - it's completely redundant.

Try this:
code:
printf("String length is %d\n",strlen("\0\0\0\0\0"));

The answer is of course zero.

You *can* access the memory where the string is stored and add whatever data you like to the end of it, but that is because you are no longer treating it as a string, you are accessing the memory as a raw object. Whenever you subsequently access it as a string the extra data past the first '\0' will be ignored.

Strings in C are not real storage objects, there is no "string" type in C. They are an abstract of character arrays, and that abstract expects them to be "any number of characters except '\0'"

This is true of KiXtart as well of course, except they are further abstracted by the interpreter, which has no provision to access the underlying storage object.

I know I've gone on a bit, but I think that it is useful to explain how the underlying storage mechanisms work, as it makes it easier to understand why some things work (or don't work) the way that they do.


NTDOCAdministrator
(KiX Master)
2002-06-12 10:19 AM
Re: Instr() Behaviour

Quote by Howard [Eek!] hehehe I mean Richard:

Don't forget that KiXtart is an interpreted language. There is a program which is reading the code and translating it. That program is written in...?

code:
KIX32.EXE (204800 bytes)

Is a DOS executable
Size of header.....: 00000040h / 64 bytes
File size in header: 00000490h / 1168 bytes
Entrypoint.........: 00000040h / 64
Overlay size.......: 00031B70h / 203632
No relocation entries

PE EXE at offset 256/00000100h
Entrypoint: 0001BDC8h / 114120 (RVA: 0001BDC8h) (.text)
Calculated PE EXE size: 00032000h / 204800
Calculated overlay size: 00000000h / 0
Image base: 00400000h
Required CPU type: 80386
Required OS: 4.00 - Win 95 or NT 4
Subsystem: Console
Linker version: 6.00
Flags:
Relocation info stripped from file
File is executable
Line numbers stripped from file
Local symbols stripped from file
Machine based on 32-bit-word architecture
Stack reserve: 00100000h / 1048576
Stack commit: 00001000h / 4096
Heap reserve: 00100000h / 1048576
Heap commit: 00001000h / 4096

Sections according to section table (section align = 00001000h):
Name Virt size RVA Phys size Phys offs
.text 00023914h 00001000h 00024000h 00001000h
.rdata 0000264Eh 00025000h 00003000h 00025000h
.data 0001B6D4h 00028000h 00009000h 00028000h
.rsrc 000003F0h 00044000h 00001000h 00031000h

Listing of all used data directory entries (used: 3, total: 16):
Import Table - offset: 000261FCh - RVA: 000261FCh (.rdata)
Ressource Table - offset: 00031000h - RVA: 00044000h (.rsrc)
Import Address Table - offset: 00025000h - RVA: 00025000h (.rdata)

Resources at offset 00031000h (RVA 00044000h):
Version:
ID: 0x00000001h RVA: 0x00044060h; Offset: 0x0003105Fh; Size: 908 bytes
VersionInfo resource:
Fileversion: 4.02.00 (0)
Productversion: 4.02.00 (63)
Target OS: 32 bit Windows running with MS-DOS

Total resource size: 996 bytes (ressources: 908 bytes, table: 88 bytes)

Processed with:
Found compiler 'Visual C++ 5.0 ?'
Seems to be compiled by MS Visual C++ 6.0

However, since the KiXtart 2001 manual already tells us, I guess I did not need to trace the file type.

From page 111 of the 2001 manual you have.

About KiXtart
KiXtart 2001 is a spare time project of Ruud van Velsen of Microsoft Netherlands.

KiXtart was developed on Windows XP using Microsoft Visual Studio, Microsoft Visual C 6.0 SP4, Microsoft Assembler 6.1 and the Windows 32 Software Development Kit.

The SPK format used by the PLAY command was originally designed by Gordon E. Peterson II. The SPK files were translated from BASIC and Assembler programs gathered from various public domain sources

[Cool]


LonkeroAdministrator
(KiX Master Guru)
2002-06-12 10:37 AM
Re: Instr() Behaviour

howie...
this is weird, I've allways read your name to be richard howard!

don't know why. but how* sounds better than ric* (notice the hard tasting c there...)

but as it comes to the c again.

have you tried writing string like:
"my fellow"
added the null to fourth place:
"my "
and then added as example 1 in its place.
"my 1 fellow"

?


Richard H.Administrator
(KiX Supporter)
2002-06-12 11:34 AM
Re: Instr() Behaviour

Perhaps you're confusing me with Howard Bullock.

Your example illustrates what I was saying.

When you place the '\0' in the fourth character position you are terminating the string there. No string functions will read past it - whatever is past the third character is unavailable.

If you want to access the rest of the data beyond character 4 you will need to do it a different way, string semantics won't do it for you.

Replacing the '\0' with another character means that it will read up to the next '\0', which will be at the end of your original string, unless something else has used the memory beyond the '\0' in which case you will get garbage.

In your example, the final string would be
"my 1ellow"

[ 12 June 2002, 11:38: Message edited by: Richard Howarth ]


LonkeroAdministrator
(KiX Master Guru)
2002-06-13 12:01 AM
Re: Instr() Behaviour

I know that there is difference between richard howie and howard bullock (uttleast I suppose so).

but anyhow...

my example went broken when bb cuts empty spaces... it had 3 tabs...


Jack Lothian
(MM club member)
2002-06-12 06:52 PM
Re: Instr() Behaviour

Richard,

I am afraid I started this calling of you Howard. I corrected my mistake shortly after but unforunately is seems to have stuck in others members head. I am sorry.

Brian,

I have been busy lately & this is a complex subject so I have no time to develop a respond to your comments.

I don't think I expressed myself very well. I believe this discussion is about a fundamental paradox. I do believe it closely parallels Bertrand Russell's paradox. The basic paradox is an infinite number of nothings exist in everything. Like Russell's paradox, it can not be resolved unless you apply extra constraints or axioms to your logic system.

You say 0 is the best value to return because there is a nothing just in front of your string. But there is another nothing in front of that nothing so maybe -1 is better. Of course we can continue this arguement forever until we arrive at minus infinity. Clearly, an infinite number of contradictory results can be obtained. Neither 0 or 1 is a consistent result. When using symbolic logic you must be very careful when any of the symbols can take on a value of 0 or infinity. Most logical proofs break down when values of 0 or ininity are introduced.

Lonkero's solution has strong merits. A return of an error explicitly tells the user that this can not be solved within the current logic system. In essence the user has asked the unanswerable.

I believe you can add constraints to the logic system that enables one to always derive an answer of 1 but never 0. (Unless of couse you always start your countings at 0 like some computer do. These languages define arrays starting from position 0 onwards.)

I am not sure you can add constraints that develop a closed logic system that only counts nothings once. To return 0, I think you need such a constraint to consistently derive your answer.

From the point of view of a programming language though I see no great issue with returning 0. Of course, the user will not be able to tell the difference between not finding it & it was impossible to look. Both of these cases will return a zero.


Howard Bullock
(KiX Supporter)
2002-06-12 07:19 PM
Re: Instr() Behaviour

I am just glad that I haven't been posting these comments to which I was unaware. [Wink]

[ 12 June 2002, 19:19: Message edited by: Howard Bullock ]


BrianTX
(Korg Regular)
2002-06-12 10:18 PM
Re: Instr() Behaviour

Hmmm.. interesting points, Jack.

I can easily understand how you can define a boolean system of proofs to decide that an empty set (or sequence) is always in every set (or sequence), so you would return a value of "YES" (or 1) to validate that one sequence intersects another. However, (implied from what you said) you can have an infinite number of empty sequences before or after a defined sequence, so these empty sets could be indexed to infinity in one direction or the other....

The only problem with this theory is that INSTR is defined by calculating first IF a string exists in another string AND the index of that string as defined by numbering the characters in the string. Because the empty sequences before and after the characters that exist are not defined, it would be impossible to define an empty sequence using one of the numbers that already defines a starting point that does exist in the string.

For example:
INSTR("abc","A") = INSTR("abc","") = 1 should NOT be true.

If indeed INSTR("abc","d") = INSTR("abc","")=0 should not be true either because the two conditions are not identical, then two different return codes should be chosen for each case UNLESS it is unnecessary to distinguish between the two situations. Perhaps the easiest way to solve this problem would be to let:

INSTR("abc","d") = 0 with @error = 0
and
INSTR("abc","") = 0 with @error = something(1, or -1)

The 0 represents that the 2nd string has no index in the first. The @error represents whether or not the 2nd string is an empty set.

This way people that don't care to distinguish between the 2 latter evaluations would have to write no additional code to handle them. Those of us that may at some point wish to handle them will have an alternative to do so.

Brian

[ 13 June 2002, 14:24: Message edited by: BrianTX ]


Bxn
(Getting the hang of it)
2002-06-13 10:31 AM
Re: Instr() Behaviour

Interestin' Indeed !
But I suggest you to apply the new jokin' function :

Replace(Substr(Dummy),Instr(Dummy))

Just to stay on Topic [Big Grin]


LonkeroAdministrator
(KiX Master Guru)
2002-06-13 10:46 AM
Re: Instr() Behaviour

but what was the topic?

{edit}
checked and yes, it's about instr...

[ 13 June 2002, 10:47: Message edited by: Lonkero ]


BrianTX
(Korg Regular)
2002-06-13 02:23 PM
Re: Instr() Behaviour

Oops.. lol.. geez.. that's what I meant.. let me fix that! lol -- It's called "absent-minded professor syndrome!"

Brian

[ 13 June 2002, 14:25: Message edited by: BrianTX ]


Ruud van Velsen
(Hey THIS is FUN)
2002-08-23 08:43 AM
Re: Instr() Behaviour

Better late than never, I hope: the long and shotr of why InStr returns 1 if you search for an empty string is... that it is compatible with the implementation of InStr in other languages (such as Visual Basic).

Maybe not the exciting answer you were looking for, but there you go ;-)

Ruud


Sealeopard
(KiX Master)
2002-08-23 04:16 PM
Re: Instr() Behaviour

That's actually a very good and reasonable explanation [Smile]

LonkeroAdministrator
(KiX Master Guru)
2002-08-24 03:11 AM
Re: Instr() Behaviour

still, it does not make any explanation at all. as I think of, it was made as a quickie instr-support to have kix be as much as possible like vb...

well, kix ain't like that. kix is purely independent in many cases and these likelyhoods, if questioned, should also be discussed...

anyway, as ruud's project, he can rule on these and my opinion just is that opinions are good.


Jack Lothian
(MM club member)
2002-08-24 05:20 AM
Re: Instr() Behaviour

Brian,

Sorry for my late comment but I was busy that week & I never looked back in on this discussion & I missed your comments.

You suggest that

quote:

For example:
INSTR("abc","A") = INSTR("abc","") = 1 should NOT be true.

Why? Looking for "nothing" fundamentally violates the logic system so why couldn't it return an illogical answer.

I agree my patch or constraint on the logic doesn't resolve all the logical conflicts but I am not sure that there is any constraint that is logically consistent in every circumstance.

A point:

If ""="" is true would it be logical to have INSTR("","") be false?

I don't think there is a logical answer to this debate & Ruud's reason is as good as any.

[ 24. August 2002, 05:27: Message edited by: Jack Lothian ]


Bxn
(Getting the hang of it)
2002-08-26 05:30 PM
Re: Instr() Behaviour

I see I've introduced Lots Of "verbiage" for nothing ...

Will I be wrong another time if I suggest little mods in doc (to alert newbees and not CompatibilityAware people like me, that this function "... does not always return the first occurence ...")?


LonkeroAdministrator
(KiX Master Guru)
2002-08-26 07:49 PM
Re: Instr() Behaviour

bxn, it could be done but with not those words.

as it would state:
"function does not always work"

[Big Grin]

[ 26. August 2002, 20:12: Message edited by: Lonkero ]


Bxn
(Getting the hang of it)
2002-08-26 09:10 PM
Re: Instr() Behaviour

Yes, Of Course, I guess it was [Bad] Humour From Me ...

May my unmeasured (and unwanted) agressivity be forgiven ???


LonkeroAdministrator
(KiX Master Guru)
2002-08-26 09:48 PM
Re: Instr() Behaviour

forgiven?... most likely.
recorded in history?... for sure.

you can run but you can not hide [Razz]

ok, I had my fun...
 


Bxn
(Getting the hang of it)
2002-08-27 11:05 PM
Re: Instr() Behaviour

History is full of black lists ...
Despite my little experience of web/net forums, sounds like a confirmation I'm on such a list ...
You wrote you had your fun, I didn't, don't and now won't have mine ...
That wasn't my goal ...


LonkeroAdministrator
(KiX Master Guru)
2002-08-27 11:30 PM
Re: Instr() Behaviour

bxn, it isn't banned (yet...) either.

if having bad/untasty/un-understandable/mistakenly said/... humour would be banned, I would be banned totally at the same time.


Bxn
(Getting the hang of it)
2002-09-05 08:57 AM
Re: Instr() Behaviour

Copy !
Let's keep humour high ...