PB Editor Suggestion

[Haitham Yousef]

I would like to suggest some enhancements to the current PB editor and would like to see what other PB users think of them, or maybe they would like to add to my list.

1- Underlining user variables that need to be DIMed. The user can see all the variables that need to be DIMed and act on them instead waiting for the compiler to flag them one at a time. The underlining idea is similar to MS Word when the user types a word that is not in the dictionary.

It would be really cool if the user then right-clicks on any of the underlined variables and then selects the variable type from the multitude of types supported by PB and the editor automatically adds 'DIM AbcdEfgh as BYTE' (for example) at the top of the current function/subroutine.

2- As in VB editor, if the user writes a variable name in a certain way then whenever subsequently the name appears in the code it will be written in the same way it was first written. This would save pressing the shift key to get the desired letter capitalizations every time the variable is typed.

3- As in VB editor, typing any of PB statements would force the editor to display a bubble message showing the statements's arguments list.

[John Gleason]

good suggestions all! I second those motions.

[Fred Buffington]

I third it ! for both pbcc and pbwin. with the option to turn these off/on.

[Rodney Hicks]

Tos suggest them to PB, send your list to
[email protected]\

Rod

[John Gleason]

Tos suggest them to PB, send your list to
[email protected]ic.com\

Rod

done.

[Michael Mattias]

>Underlining user variables that need to be DIMed

How is the compiler supposed to know that "foobar" is a user variable and not a typo for "FUNCTION?"

Maybe you mean "highlight any 'word' which cannot be recognized as either a keyword or an already-defined (via DIM/REDIM, LOCAL/GLOBAL/STATIC/REGISTER/THREADED statement, or a passed parameter variable name) user variable.

The problem with this is, now EVERYTHING is highlighted because keywords already are highlighted. That screen is going to look terrible (unless you operate with keyword highlighting turned off).

If you want to go the highlight route, perhaps better to highlight keywords in one color, KNOWN user-variables in another, leaving "mystery words" un-highlighted?

Or perhaps, a variation of the the long-ago asked for "compile for syntax only" might have an option to "identify mystery words, which must be either typos or undefined user variables?"

How do the third-party IDE people do this? Do they even do something like this?

[Emanuele Colombo]

At the moment, I prefer "not-VBlike-compiler" instead of "VBlike editor".
Anyway, JellyFish+Lynx is a good pair for edit PB code.

[Barry Erick]

Well, a word with an equals sign must be a variable. If not recognized, it must be a variable. Does that not make sense?

But, checking syntax is a function of the compiler and not the editor. However it could keep track of DIM;s (including local and globals) and work with that.

[Hans-Dieter Veit]

But, checking syntax is a function of the compiler and not the editor.

Yes, but a pre checking already during input (by the editor) of code can save much trouble and time during (trying to) compile.

Hans

[Joe Byrne]

Yes, but a pre checking already during input (by the editor) of code can save much trouble and time during (trying to) compile.
Hans

Gee, I have a couple of huge apps and not one that takes more than a few seconds (if that) to compile. Its not like the process takes minutes or hours AFAIK.

[Gary Barnes]

Hi,

1. I would like to add a split function to the editor windows - makes it much easier to look at separated but related code blocks.

2. Optional Folding of Subs and Functions. - This would significantly reduce code clutter.

Otherwise I think that the PB editors are pretty good.

Mind you Jellyfish comes pretty close to an ideal editor for PB.

Regards

[Rodney Hicks]

1. I would like to add a split function to the editor windows - makes it much easier to look at separated but related code blocks.

2. Optional Folding of Subs and Functions. - This would significantly reduce code clutter.

Both are good ideas but #2 could work just as well with 'Edit'-'Block Selection'-'Fold/Unfold'
Didja send in a New Feature Suggestion?

Rod

[Gary Barnes]

Rodney,

Have I sent in them as an NFS?
Ummmmm, well not yet.

I can see how Block Fold and Unfold could work and it would be more practical than a Global fold.
I suppose that it should be Subs, Function and Macro's.

I will send them into PB as a NFS after I knock them into shape (in a literary sense that is)

Cheers

[Tyrone W. Lee]

Well..

I like those ideas.. I think that FireFly is one of the best PB editors that moves in the direction of a VB-Like IDE/editor.

That said, I'd like to see a TOTALLY original idea added to any of the BASIC editors I've used. (UDT managing)

For example if I created a UDT: (in an old or non-Windows based BASIC editor)

TYPE Address
  Name as string *255
  Phone as string * 30
  Icon as long
END TYPE

When it is ported to PowerBASIC, the word "ICON" could/would be a keyword and cause an error in the compile. I would like to change the UDT from "Icon" to "hIcon" and have the IDE find all the variables using this type and replace <variable>.Icon with <variable>.hIcon.

Right now, I use a file replace program called Replace'Em, which does a great job. But an IDE that could do this would be awesome. It would allow "old code" to get quicker/more professional field names quickly.

The PB/IDE doesn't really handle Projects and all associated files as well as FireFly, so that would be needed for this feature to be implemented.

Just a thought..

Tye

[José Roca]

When it is ported to PowerBASIC, the word "ICON" could/would be a keyword and cause an error in the compile.

You must be using an old version of the compiler, because currently the only keyword that can cause an error if used as a member name is END.

[Richard Angell]

Tyrone,

Maybe not an old version ... but you should ignore the syntax highlighting in the member definition. The PB Editor has not yet removed case change and keyword highlighting from such legitimate member names in declarations of TYPES and UNIONS. See example. load and try:

#COMPILE EXE
#DIM ALL
TYPE Address
  NAME AS STRING *255
  Phone AS STRING * 30
  ICON AS LONG
END TYPE

FUNCTION PBMAIN () AS LONG
    DIM mybb(1 TO 10) AS Address
    
    mybb(1).NAME  = "Sam Smith"
    mybb(1).Phone = "BR-599"
    mybb(1).ICON  = 101
    
    ?  TRIM$(mybb(1).NAME) + $CRLF + TRIM$(mybb(1).phone)  + $CRLF + _
       "icon #" + TRIM$(FORMAT$(mybb(1).ICON))

END FUNCTION

[Michael Mattias]

You must be using an old version of the compiler, because currently the only keyword that can cause an error if used as a member name is END

"End" has other problems.

Yesterday I coded like this...

DO 
 IF  ..... THEN
   IF .... THEN 
   ELSE
      IF ... THEN 
       ....
      END [b]OF[/b]
   END IF
 
 ELSE

 END IF    
LOOP

Actual code about three screens' worth (what's that, maybe 150 lines?)

Compiler got to END FUNCTION and told me I had some kind of Loop missing. I "finally" traced the problem to using "END OF" instead of "END IF"

Seems to me "END OF" is its own error and that's the row:col where the error should have been reported. When "END" is the first word of the statement it can only legally followed by IF, SELECT, TRY, SUB, FUNCTION, UNION, TYPE etc.

(this was PB/WIN 8.03)


MCM

[Bill Franke]

I'd like to be able to drag and drop text.

[Bob Zale]

"End" has other problems.

Actually, END has no other problems.

When parsing reached the LOOP statement, the matching open block statement was an IF statement. PowerBASIC would have been pleased to have found an END IF (to close that open IF, or another DO (to open the block terminated with LOOP). It chose to suggest that a DO was expected, but there are many other ways you could have satisfied the pure syntax requirements.

PowerBASIC is a two pass compiler. Some errors are caught on pass 1, some on pass 2.

Best regards,

Bob Zale
PowerBASIC Inc.

[Michael Mattias]

>Some errors are caught on pass 1, some on pass 2.

Ok, I see what you mean, but....

But shouldn't "END <invalid word>" be part of the "very" first pass? Then you never even get to point where you'd have a missing "END IF" (or "END anything_valid")

?????

----------
Suzy User