Interesting IDE effect noticed

[OldMoses]

I've come across an interesting issue with the IDE. I've been programming a role playing character generator and it uses several user defined variable types. My IDE colors are set to the QB64 default setting. Variables are bright white and keywords are light blue.

Here is one of my variable types:

TYPE skill
    ident AS INTEGER 'unique ID # of skill
    name AS STRING * 18 'name of skill
    category AS STRING * 4 'category of skill
    value AS INTEGER 'percentage of skill
    base_per AS INTEGER 'base of skill
    cat_per AS INTEGER 'category modifier
    modified AS INTEGER 'number of modifications
    exchk AS INTEGER 'experience check flag
END TYPE

Now the funny thing is, the 'name AS STRING * 18' element, unlike the rest of the elements, displays the "name" in keyword color, instead of white as the others are. There are two more variable types defined that also use 'name' as an element and they display the same way. I know now (having looked it up) that NAME is a keyword, which I do not use in its keyword capacity any where in the program, nor does it color the '{variable}.name' anywhere else in the program except within the TYPE declaration, but here's where it gets a little wierd.

It displays as the keyword color, but doesn't attempt to capitalize 'name', nor does the program have any errors related to that element. It runs just as expected in that respect. No issues that I can see.

Have I found a quirk of the IDE's keyword recognition, and does anyone think I should be changing the element as a precaution?

[TerryRitchie]

Name is a reserved word in Qbasic therefore the IDE is probably coloring it as such. More than likely the IDE will need a little tweaking to skip reserve word checks inside of TYPE constructs.

[FellippeHeitor]

The way QB64's syntax highlighter currently works is by analyzing each visible line of code and checking, character by character, against (i) a list of internal commands names, (ii) the list of user-defined keywords (check internal/config.txt for instructions on how to add custom keywords and (iii) user's SUB/FUNCTION names. No check at all is made concerning scope, which would solve this problem, but that doesn't mean it can't be done in a future release.

I thank you guys for reporting it, although it was already known - one of those things you let slip and hope no one will complain about. Guilty as charged.

[TerryRitchie]

I remember the IDE from way back in .8x days of QB64. It has come a long way since then. A little highlighting glitch is nothing compared to the rich features it offers today. Heck, back then there was no highlighting at all. Thanks for keeping the IDE up to date Fillippe!

[FellippeHeitor]

My pleasure, Terry!

Thanks also to Steve's effort, who implemented the embryo for the current expanded highlight implementation.

[TerryRitchie]

Thanks also to Steve's effort, who implemented the embryo for the current expanded highlight implementation.

Oh I didn't know that. Cool, thanks Steve! :)

[FellippeHeitor]

Have I found a quirk of the IDE's keyword recognition, and does anyone think I should be changing the element as a precaution?

No need to change the element name at all, unless the highlight in the TYPE block bothers you (the element won't be highlighted any different when used in variable names later - see screenshot below).

 [ You are not allowed to view this attachment ]  

Other than that, no issues for the workings of your program at all.

[SMcNeill]

As a related issue:

Since  QB64 doesn't work with FN, and since FN isn't a reserved keyword (it's a perfectly valid variable name), shouldn't it be excluded from the reserved word list, which is used to color/highlight the text?

DIM SHARED FW AS ObjectDimensions, FN  AS ObjectDimensions, FE AS ObjectDimensions, FS AS ObjectDimensions

The above code colors FN blue in the idea, just as it would any other reserved keyword -- even though it's a perfectly valid variable name.

[FellippeHeitor]

Definitely!

[bplus]

Here is one I ran into yesterday using QB64x64 but it also is on latest Beta. Usually the IDE changes case of variable spelling to match the first one it finds but in ubound and now I see lbound, not so, still it does not effect performance.

[FellippeHeitor]

That's known (and old) too. Never figured how to fix it.

[TempodiBasic]

Hi QB64 developers
just a question for curiosity, to let know and no other matter.

it is OK that FN is not implemented!
it is OK that to port a Qbasic/QB code, that uses FN functions, to QB64 it is possible rewrite the FN function as Function..... End Function

Who  does remember the matter that brings FN out of supported QB's  keywords?
Thanks

[OldMoses]

Have I found a quirk of the IDE's keyword recognition, and does anyone think I should be changing the element as a precaution?

No need to change the element name at all, unless the highlight in the TYPE block bothers you (the element won't be highlighted any different when used in variable names later - see screenshot below).

Other than that, no issues for the workings of your program at all.

Thanks, I thought it would be OK, but it's nice to have verification.

I'll also take this opportunity to thank you guys for QB64, it's so nice to resurrect old programs, escape DOS emulators, have mouse support, etc., etc.

I've just spent the afternoon playing with _NEWIMAGE, _RGB32, et. al. So much to see and do, my head might explode...;)

[TerryRitchie]

I've just spent the afternoon playing with _NEWIMAGE, _RGB32, et. al. So much to see and do, my head might explode...;)

That's exactly how I felt when first discovered QB64 back in 2010. I was like a kid in a candy store.