A couple of small things for the wishlist.

[Peter Scheutz]

Hi all

I would like to add these things to the wishlist.

1.) Stop the compiler from complaining over this valid code:

Sub DotheRedim( a() As Long)
    ReDim a(10)
End Sub

Sub TestRedim()
    Local myArray() As Long
    ' redim myArray () ' this is needed to stop the compiler from complaining
    ' alerting that myArray has not been dimensioned.
    DotheRedim myArray()
    MsgBox Str$(myArray(3))
End Sub

2.) A built-in " #IDE_DEBUG PRINT statement

It would be really nice to have an option to debug print to a window in the IDE. (Without using the debugger)
The functionality could be turned on/off by a "#ENABLE IDE_DEBUG" option.
Maybe the output could be redirected to a file, for those using another IDE.


And maybe:

3.) Syntax highligting of "Declared" Subs and Functions, such as the windows API and other includes.
As this might influence the speed of the Editor, there could be an option to turn it off and on.

--
Best Regards
Peter Scheutz


------------------


[This message has been edited by Peter Scheutz (edited January 17, 2001).]

[Gregery D Engle]

Peter,

This works fine for me:

#COMPILE EXE

SUB DotheRedim( a() AS LONG)
    REDIM a(10)
END SUB

SUB TestRedim()
    DIM myArray(0 TO 0) AS LONG
    ' redim myArray () ' this is needed to stop the compiler from complaining
    ' alerting that myArray has not been dimensioned.
    DotheRedim myArray()
    MSGBOX STR$(myArray(3))
END SUB

FUNCTION PBMAIN() AS LONG
TestRedim
END FUNCTION

------------------
-Greg

[jcfuller]

Peter,
Re: Debug Print.
You may find this useful.
www.jcfuller.com/ADPDP.ZIP

James


------------------

[Lance Edmonds]

Peter, the statement LOCAL myArray() AS LONG is a scanned statement.

This is used only during compilation, and informs the compiler that you are going to be creating a LOCAL array somewhere in the current sub/function.

However, since the array is not explicitly dimensioned before you have attempted to use it in the function call statement, the code is actually incomplete and you _should_ correctly receive a compile-time error. On this basis, the error message is completely valid and accurate.

The only way to change this behavior would be for the compiler to automatically DIM an array to, say, 11 subscripts unless an explicit DIM statement is encountered first (like many DOS Basic dialects do).

Personally, I prefer to control the array size myself, and so I personally believe the compilers behavior should not be changed.

Greg showed the easiest way to declare your array - simply DIM it in the first place and omit the LOCAL statement altogether. However, for clarity of yourt code, you can "combine" the two statements, thus:

DIM myArray(1:10) AS LOCAL LONG

Regarding the DEBUG IDE_PRINT suggestion... James' solution is excellent. When you choose the EXECUTE option in the IDE, the code is compiled and launched as a separate process. In this state, the IDE is not active, so any kind of debugging code needs to be built into the EXE proper. This would mean that you would have to remember to switch off that kind of debugging code generation, and that adds an extra step to remember when compiling "release" code. OTOH, I guess the #DEBUG ERROR ON meta-statement works in the same manner, but then you would be faced with up to two meta-statements to set correctly before compilation.

I recall that there was some code in the source coide forum that works in a similar way to James Fullers DEBUG library... seach the Source Code Forum (and/or the Source Code Archive) for "allocconsole" and you should find it.

Finally, I would like to see the syntax high-lighting of subs/functions too... it would be very handy! James' IDE (PBWINADP) offers this ability and I love it for that fact alone!

I hope this helps!


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Peter Scheutz]

Thanks Gregery, James and Lance.

Originally posted by Lance Edmonds:

[SNIP]
Personally, I prefer to control the array size myself, and so I personally believe the compilers behavior should not be changed.

Greg showed the easiest way to declare your array - simply DIM it in the first place and omit the LOCAL statement altogether. However, for clarity of yourt code, you can "combine" the two statements, thus:

DIM myArray(1:10) AS LOCAL LONG

I guess it depends on personal preferences, and coding style.
Sending an array to another Function/Sub with Ubound -1 has it's advantages.
I'll stick with the redim()/(Erase) statement.
I still maintain the suggestion though

Regarding the DEBUG IDE_PRINT suggestion... James' solution is excellent. When you choose the EXECUTE option in the IDE, the code is compiled and launched as a separate process. In this state, the IDE is not active, so any kind of debugging code needs to be built into the EXE proper. This would mean that you would have to remember to switch off that kind of debugging code generation, and that adds an extra step to remember when compiling "release" code. OTOH, I guess the #DEBUG ERROR ON meta-statement works in the same manner, but then you would be faced with up to two meta-statements to set correctly before compilation.

I recall that there was some code in the source coide forum that works in a similar way to James Fullers DEBUG library... seach the Source Code Forum (and/or the Source Code Archive) for "allocconsole" and you should find it.

I am aware of this, but believe I could handle the meta-statements.
I still think Powerbasic should look into a one-statement built-in soulution.

Finally, I would like to see the syntax high-lighting of subs/functions too... it would be very handy! James' IDE (PBWINADP) offers this ability and I love it for that fact alone!

I hope this helps!

Yes, a lot of credit should go to the independant PB IDE/Builder creators.
Will the day come, when they join forces and start a sourceForge project?

BTW: I forgot two editor features I would appreciate:

Block indent/outdent.
Block comment/uncomment.

Just my 2 øre...


--
Peter Scheutz


------------------




[This message has been edited by Peter Scheutz (edited January 18, 2001).]

[Peter Scheutz]

Originally posted by Lance Edmonds:

...
I recall that there was some code in the source coide forum that works in a similar way to James Fullers DEBUG library...

Hi Lance

I found this cool solution by Edwin Knoppert on his site:

http://pbsoft.bkln.net/download/pbaddin.zip

Description:

Addin for PBEdit, this makes it possible to interact with PBEdit.
Open files with drag & drop, navigationbar, add menus etc..
Debug Print functionality (interacts from your(!) app to PBEdit)
A fully working project and DLL is available.

--
Best Regards
Peter Scheutz



------------------

[Lance Edmonds]

Yes, I'm aware of that project, but because it tampers directly with the executable code of PBEDIT, we can not recommend or support it in any way - it a 3rd-party "patch" afterall.

If you use it, you do so at your own risk and accept the result of any problems it may cause.



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>