Wishlist of features for PB7! 
Author Message
 Wishlist of features for PB7!

It would be nice if we can get the following productivity enhancements to
the next version of PB:

1. IDE
    a. Project-Oriented (project explorer with context menus to add/remove
source files)
    b. Incremental Compilation (will really help with large source files)
    c.  Some wizards to quickly generate common user interface components
(such as Dialogs) and application frameworks (such as a DLL that exports a
single method; just something to get started; PB is not object-oriented so
forget about Inheritance).
    d. TODO List. Clicking an entry in the list might open the respective
source file and put the cursor on the bookmarked line. (*Desperately
Needed*)
    e. Ability to connect to ODBC sources and view ODBC data from within
IDE. Asking for much?
    f. Ability to work with resource (.RES) files. Require native methods to
manipulate resources. Very important for localizing apps. This might mean
modifying the compiler itself.

2. Language Components
    a. Native methods to work with the Windows File System, Clipboard, Win32
Internet functions (WinInet), Registry and the NT Event Log. Example:

        If FileExists(sFileName) = 1 Then
        ' file does exist; open file and return a handle to open file
            glFile = OpenFile(sFileName, OF_READONLY)
        ' read the first line of the open file into a variable; this might
move cursor to the next line
            sCurLine = ReadLine(glLine) ' or maybe ReadLine(glLine, 1)
        ' move cursor back to first line
            Call GotoLine(glLine, 1)     ' or maybe SetCursorToLine(glLine,
1)
        End If

    b. Native methods to perform drag and drop operations; work with XML;
probably a few others but can't think of them right now. One of those memory
lapses...

3. Other
    a.  Need some form of strong *native* database support. Asking for much?
SQL Tools is good. I wonder if SQL Tools will come integrated with the next
version of PB.
    b. Ability to natively construct something like a Grid, ProgressBar or a
TreeView instead of using the Win32 API directly (*Sigh*). DDT is alright
but needs improvement.

I know that I need an improved PB to write applications that my users will
like.

-----------------------------------------------
Gregor Horvath Wrote:

"VB.NET will IMHO not be BASIC anymore. (except the name)

It looks more like C/C++ or delphi (Pascal).
Basic concepts are thrown away.

Therefore there will be a whole in the market for current VB Developers
which want still develop in (real) Basic.

Will powerbasic fill that market?
Are there any plans to strenghten the GUI capabilities of PowerBasic?
Are there any plans to enable an easy port from VB to PowerBasic?"
-------------------------------------------------

VB.NET is a lot different from VB6, yes. I don't think that VB Programmers
will even think of moving to PB largely for three reasons:

    1. PB's current IDE is not as good as the VB IDE which has some advanced
editor refinements such as IntelliSense technology and the ability to work
with multiple projects (and builds). VB also has integrated source code
control support (*Yum*).
    2. PB relies to a large extent on the Win32 API and a large amount of VB
Programmers may not know how to work with the Win32 API (and hence the need
for native methods in PB7).
    3. If a VB6 Programmer is used to Interface-based programming , he/she
will definitely not (unless he/she is a loyal fan of PB) make a move to PB7
unless PB7 supports Interface-based programming as well (which would mean a
phenomenal amount of effort for the PB team). Then there is the huge issue
of porting existing Interface-based code to procedural (and/or
message-based) code. Yuk! I can't imagine any decent IT Manager in his/her
right mind approving a port like that.

So whether they go toward VB.NET or PB7, "regular" VB6 Programmers will
still face a steep learning curve either way and might just opt for Redmond
seeing how Microsoft's other products integrate with VS.NET. But as Gregor
implied, if PB7 is feature-rich enough, we might see a lot of VB->PB
converts.



Mon, 12 Jan 2004 12:28:46 GMT  
 Wishlist of features for PB7!

Quote:
> It would be nice if we can get the following productivity enhancements to
> the next version of PB:

My other reply was more general in nature; let me deal with some of your
specifics in this one.

Quote:
> 1. IDE
>     a. Project-Oriented (project explorer with context menus to add/remove
> source files)

Huh? If you don't need the file, why did you add the file to begin with? If
these are, like, common routines, you should put them in a DLL. No muss, no
fuss, no bother.

Quote:
>     b. Incremental Compilation (will really help with large source files)

Better would be an options fo: "compile for syntax only (no code
generation)"

Better still would be, "Compile for syntax, but do not stop on first error.
Keep compiling, and write all errors found to a text file."  Then, on that
"first compile" of a new program, you can fix all the obvious errors (typos,
missing parentheses, etc) with only one compile and re-editing session.
(Because one typo in a file can cause multiple errors in the source later,
it would take some getting used to. But COBOL programmers (like me) are
already used to this.)

Quote:
>     c.  Some wizards to quickly generate common user interface components
> (such as Dialogs) and application frameworks (such as a DLL that exports a
> single method; just something to get started; PB is not object-oriented so
> forget about Inheritance).

PB/DLL comes with some tools to do this, as well as some sample code. The
best code might be the converted "GADGETS" program from Mr. Petzold's book.
Someone (I forget who) converted all the examples from Petzold's "C" to PB;
I never used it, but lots of folks rave about it.

Methods are out (see my other post re changing the product). Besides, you
CAN do the things "methods" allow you to do, but coding it is a dog.

Quote:
>     d. TODO List. Clicking an entry in the list might open the respective
> source file and put the cursor on the bookmarked line. (*Desperately
> Needed*)

Notepad.

Quote:
>     e. Ability to connect to ODBC sources and view ODBC data from within
> IDE. Asking for much?

Huh? You mean ODBC connections as part of the IDE? Just use Lotus Approach,
Microsoft Access, Oracle or even the (freeware) Win*SQL Lite. ( I use the
freeware).

Or do you mean access ODBC datasources progammatically? I do that now with
the ODBC API. (I use the native ODBC API, but there is a much-praised
product called "SQL Tools" which makes this a lot easier).

Quote:
>     f. Ability to work with resource (.RES) files. Require native methods
to
> manipulate resources. Very important for localizing apps. This might mean
> modifying the compiler itself.

What do you mean, "manipulate" resources? There's always the WinAPI calls
BeginUpdateResource,UpdateResource, etc.

(The *.RC==>*.RES ==> *.PBR process is kinda dopey; this could be
streamlined; also, the "RC.EXE"  .RES file is not the same as the
DialogEditor *RES file, so there is some confusion here).

Quote:
> 2. Language Components
>     a. Native methods to work with the Windows File System, Clipboard,
Win32
> Internet functions (WinInet), Registry and the NT Event Log. Example:

There is WinAPI access for all of this; this again goes to my other post. If
you really want "easier" in-line access to these Windows components, write
some encapsulation functions and stick 'em in a DLL.

Quote:
>     b. Native methods to perform drag and drop operations;

API.

Quote:
> work with XML;

There is a freeware DLL available to handle XML parsing, and the header
files for PB are also available. (They were converted by a PB programmer
named Florent Heyworth).

Quote:
> 3. Other
>     a.  Need some form of strong *native* database support. Asking for
much?
> SQL Tools is good. I wonder if SQL Tools will come integrated with the
next
> version of PB.

See above.

Quote:
>     b. Ability to natively construct something like a Grid, ProgressBar or
a
> TreeView instead of using the Win32 API directly (*Sigh*). DDT is alright
> but needs improvement.

You can use any control with DDT (and of course, if you use resource scripts
or CreateWindow).

DDT syntax:

CONTROL ADD
Purpose: Add a custom control to a dialog.
Syntax CONTROL ADD "classname", hDlg&, id&, txt$, x, y, xx, yy, [, style&[,
exstyle&]] [CALL callbackfunction]

MCM



Mon, 12 Jan 2004 23:05:47 GMT  
 Wishlist of features for PB7!
7/26/01

For the last month or so I have been working almost exclusively in PB/DLL
version 6; probably the longest extended period I have done so.

For my money,  the most important upgrades PB can make are to..

1. Fix the compiler itself so that is does not GPF when the source file is
too large.
2. Get all the errors, omissions and mistatements in the documentation
fixed.
3. Fix the bugs in FORMAT$ and ARRAY INSERT/ARRAY DELETE.
4. Support long file names for #INCLUDE, #COMPILE and #RESOURCE

(Well, Ok, I can *live* without lfns, but damn, they would help). (A lot).

(Well, the IDE could use some help, but that's secondary).

As for all the stuff you mention, there have been any number of "new feature
requests" posted on the PB BBS; many are quite similar to yours - that is,
they ask to convert PB into Microsoft Visual Basic. But, the design
philosophies are different:

Microsoft designed their BASIC-language Windows development system to make
programming of user interfaces faster and easier, and easy-to-program
database access and web support. The cost for this is lack of full access to
all the features of the Windows API, a substantial run-time requirement
(both components and run-time system resources), the need to use a
"deployment package" for installation and a higher price for the development
product itself.

PowerBASIC designed their compiler to provide a solid platform for access to
all the features of the Windows API, a reasonable low cost to the developer,
minimal run-time requirement (effectively zero) and easy deployment. The
cost is it takes more time and a higher skill level to write applications
(meaning the development cost is higher, and can be substantially higher).

There could not be a starker contrast in the overall design philosophies.

Both MS and PB made conscious decisions about how their development products
would work; each has fairly taken their chances in the market.

As a consumer/developer, I like the idea of having more options available. I
will choose the methods I use to develop applications, and I, too, will take
my chances in the market.  I don't want my choices restricted to the color
of the package in which Visual BASIC ships.

Quote:
> I know that I need an improved PB to write applications that my users will

like.

I don't. After all, it's not the paintbrush, it's the artist.

--
Michael Mattias
Tal Systems
Racine WI USA


Quote:
> It would be nice if we can get the following productivity enhancements to
> the next version of PB:

[massive snip]


Mon, 12 Jan 2004 23:05:46 GMT  
 Wishlist of features for PB7!
Hi Gopi,

Thank you for your suggestions!   I'll be passing those along to R&D.

Quote:

>Will PowerBasic fill that market?

We are certainly going to be doing our best!  <grin>

Thanks again!

Lance
PowerBASIC Support

-------------------------------------------------------------------------
PowerBASIC, Inc.      | 800-780-7707 Sales | "We put the Power in Basic!"
316 Mid Valley Center | 831-659-8000 Voice | http://www.powerbasic.com



Mon, 12 Jan 2004 23:11:36 GMT  
 Wishlist of features for PB7!
Michael --

Quote:
> >     b. Incremental Compilation (will really help with large source files)

> Better still would be, "Compile for syntax, but do not stop on first error.
> Keep compiling, and write all errors found to a text file."

That sounds good, but the problem (as I understand it) is the possibility of a
"cascade failure".  An error like a simple typo in something like DIM ABC AS
LONG, then using ABCD instead of ABC, would cause an error on every single
reference to ABCD after that.  And if ABCD is used as a parameter in a call to a
sub or function, it would have to trip both "ABCD unrecognized" and "parameter
mismatch" in case the data type is wrong.  If an un-dimmed variable is used in a
math operation and the parser doesn't know its data type, and additional error
would have to be reported.  (Subtraction of a string from a numeric, for
example, should generate a Syntax Error,)  Or imagine how many error would be
caused by a missing or typo'd END FUNCTION.

In the end, only the first-reported error in a list of problems would be of any
real value.  You would spend time fixing problem #1 and then waste time
speculating about whether or not that fix would affect the rest of the list.

Maybe some kind of *rudimentary* syntax checking would be possible, but I don't
know enough about the order in which things are done to make a guess.   And a
good "check" could not guarantee a good final compile.

-- Eric



Tue, 13 Jan 2004 03:07:13 GMT  
 Wishlist of features for PB7!

Quote:
> Michael --

> > >     b. Incremental Compilation (will really help with large source
files)

> > Better still would be, "Compile for syntax, but do not stop on first
error.
> > Keep compiling, and write all errors found to a text file."

> That sounds good, but the problem (as I understand it) is the possibility
of a
> "cascade failure".  An error like a simple typo in something like DIM ABC
AS
> LONG, then using ABCD instead of ABC, would cause an error on every single
> reference to ABCD after that....

I mentioned that in my writeup. I KNOW this will happen. But, as I said,
COBOL programmers are used to that. With any COBOL I've ever used, the COBOL
equivalent of "DIM ABC AS LONG"  (see below) and then the use of "ABCD" to
refer to it will generate AT LEAST one error for each use of "ABCD."

I can handle it.

MCM

The COBOL equivalent to "DIM ABC AS LONG" looks like

    01  ABC        PICTURE IS S9(09) USAGE IS COMP-4.

COMP-4 is Intel format binary; S9(09) means there are nine siginificant
decimal digits, 's' means signed. Binary data comes only in two, four and 8
byte sizes (except with some compilers, where BYTE alignment is supported
even for binary).

Because you can only fit 4 decimal digits in a two-byte binary, and you can
fit nine decimal digits in a four-byte binary, the COBOL compiler will
define this item as a 32-bit Intel format signed binary : a "long"

More interest in COBOL data types? See my (free) tutorial at
http://www.flexus.com/downloads.html and get file COBDATA.ZIP.



Tue, 13 Jan 2004 18:22:34 GMT  
 Wishlist of features for PB7!

Quote:

>Michael --

>> >     b. Incremental Compilation (will really help with large source files)

>> Better still would be, "Compile for syntax, but do not stop on first error.
>> Keep compiling, and write all errors found to a text file."

>That sounds good, but the problem (as I understand it) is the possibility of a
>"cascade failure".  An error like a simple typo in something like DIM ABC AS
>LONG, then using ABCD instead of ABC, would cause an error on every single
>reference to ABCD after that.  

[...] The other day, I was thinking that, optionally, the IDE
should put the first reference to any variable (non-keyword) in
a different colour.  So if your statement

INCR abcd (i&)

showed the abcd in pink, you'd have a strong clue that you
keyed the name incorrectly.

--
cheers
Jonathan Berry
http://www.islandnet.com/~jberry/      to know more than you want



Thu, 15 Jan 2004 09:41:54 GMT  
 Wishlist of features for PB7!

Quote:


> >Michael --

> >> >     b. Incremental Compilation (will really help with large source
files)

> >> Better still would be, "Compile for syntax, but do not stop on first
error.
> >> Keep compiling, and write all errors found to a text file."

> >That sounds good, but the problem (as I understand it) is the possibility
of a
> >"cascade failure".  An error like a simple typo in something like DIM ABC
AS
> >LONG, then using ABCD instead of ABC, would cause an error on every
single
> >reference to ABCD after that.

> [...] The other day, I was thinking that, optionally, the IDE
> should put the first reference to any variable (non-keyword) in
> a different colour.  So if your statement

> INCR abcd (i&)

> showed the abcd in pink, you'd have a strong clue that you
> keyed the name incorrectly.

Might be interesting.... If you are not using #DIM ALL.  If using #DIM ALL,
then when you 'compile for syntax only' you'd get an error message in the
output for each occurence of 'ABCD'  and I'd think it would be pretty
obvious. (Without DIM all, all variables are "valid," at least t the
compiler ).

For those who have never seen a typical COBOL compiler output, errors in a
'compile for syntax only' run in PB might look something like this:

   IF Remit_Seq_no > 0 THEN   ' user selected a remittance
         ' connect to the database and call report
      IF ISTRUE (ConnectToDB(hWnd, hEnv, hDBC, OutOpt.Dbi)) THEN
         SqlCode = SQLAllocHandle (%SQL_HANDLE_STMT, hDBC, hStmt)  '
allocate a statment handle
         szStmt = "SELECT payee_id, payee_name, payer_id, payer_name,
remit_date, remit_type, remit_trace_no, remit_amt from remit_remit where
remit_seq_no = " & _
              LTRIM$(STR$(Remit_Seq_No))
         SqlCode = SQLExecDirect (hstmt, szStmt, %SQL_NTS)
         IF SqlCode = %SQL_SUCCESS THEN
            SqlCode = SQLNumResultCols (hStmt, nResultCols)
            IF nResultCol > 0 THEN       ' this query should always return
exactly one row
*** ERROR   nResultCol  UNDECLARED VARIABLE
                 REDIM szRow (0,0)
                 REDIM Column (0) AS ColumnInfoType
                 Stat = ReturnRowValues (hWnd , hStmt, Column(), szRow()
*** ERROR ')' EXPECTED
                 SqlCloseCursor hStmt
                 nRowCount = UBOUND (szRow, 2)   ' this better be exactly
one!
                 CVRD.RemitNo = FORMAT$(remit_seq_no, "####")
                 CVRD.TraceNo  =  szRow (7,1)
                 CVRD.RemitDate = szRow (5,1)
                 CVRD.PayerId   = szRow(3,1)
                 CVRD.PayerNam = szRow(4,1)
**   ERROR PayerNam invalid member  name
                 CVRD.RemitAmt  = "$" & MoneyAmtFormat (VAL(szRow(8,1)))
            ELSE
                  MSGBOX "No Results from Remittance Header Query!!!"
            END IF
         ELSE   ' error getting info from remit table
           MSGBOX "No Results from Remittance Header Query!!!"
         END IF
         ' close cursor, re-use the hstmt to get the totals from the claims
table
         SQLCloseCursor hStmt
         szStmt = "SELECT COUNT(*), SUM(submitted_chg), SUM(paid_amt) FROM
remit_claims WHERE remit_seq_no =" & LTRIM$(STR$(Remit_Seq_No))
         SqlCode = SQLExecDirect (hStmt, szStmt, %SQL_NTS)
         IF SqlCode = %SQL_SUCCESS OR sqlCode = %SQL_SUCCESS_WITH_INFO THEN
             SqlCode = SQLNumResultCols (hStmt, nResultCols)
             IF nResultCols > 0 THEN       ' this query should always return
exactly one row
                Stat = ReturnRowValues (hWnd , hStmt, Column(), szRow())
            ' Our result in in columns 1,2, 3 of row 1
                CVRD.ClaimCount =   FORMAT$(VAL(szRow(1,1)), "#,###")
                CVRD.SubmittedAmt = "$" & MoneyAmtFormat (VAL(szRow(2,1)))
                CVRD.PaidAmt      = "$" & MoneyAmtFormat (VAL(szRow(3,1)))
         ELSE
            MSGBOX "Error getting aggregates from remit_claims table"
         END IF
         SqlCloseCursor hStmt

END FUNCTION
*** ERROR END IF EXPECTED

These are all the "typing" errors it is easy to make when you first write a
chunk of code. For my money, it's a lot easier to fix these in one shot than
do four separate compiles.

MCM



Thu, 15 Jan 2004 19:50:10 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. Win32Forth Wishlist of features wanted.

2. feature{NONE} and feature{ANY}

3. Operator features and exporting features.

4. advantages of assumed shape (fortran 90 feature) over assumed size (fortran 77 feature)

5. POLL: TkCon Users: feature use and future features

6. Wishlist for packaging in Dolphin 5

7. Forth wishlist

8. A word on my Forth wishlist

9. Future MSWLogo Wishlist

10. Future MSWLogo Wishlist

11. The need for D-scussion (was Re: D Wishlist)

12. PARSE wishlist/brainstorming

 

 
Powered by phpBB® Forum Software