Propose tools to include in VB2PB

[StanHelton]

Let's use this thread to propose, discuss and select the tools we want to include in the release. Ideally, some of these (freeware, public domain) can be included under the hood as command buttons or options. We should include author credits in VB2PB's about box when we release.

Short List proposed by John:
Inclean
POFFS
PBWinSpy


This is Chris Boss's freeware DDT designer:
Freeware Dialog Designer 1.031

PBForms, not free, but nothing else is likely to be directly supported by PB Inc, and that's worth a lot.

[John R. Heathcote]

Stan,

Right now the editor is using a TreeView control as a repository for the commands available within the editor. The TreeView control can be expanded to include additional commands with very little effort, about 2 to 3 minutes is all it takes to add a new command. Likewise, 2 to 3 minutes is all it takes to remove a command.

Some additional tools to manipulate source code included with the editor. These tools are designed to be run before actual conversion takes place:

FlagUnusedProcedureVars - comments out unused variables within a procedure.

ExplodeVars - reformats variables:

LOCAL var1, var2, var3 AS LONG 

as:

LOCAL var1 AS LONG
LOCAL var2 AS LONG
LOCAL var3 AS LONG

Much easier to flag unused variables within a procedure this way.

ReplaceFuncNameEquals - reformats FUNCNAME =

SomeStuff =

to: 

FUNCTION =

ReformatDimVar - reformats variable declaration as:

DIM var AS LONG

to:

LOCAL var AS LONG

ReformatArgList - reformats a procedure argument list as:

FUNCTION SomeStuff (var1 AS LONG, var2 AS LONG, var3 AS LONG) AS LONG

To:

FUNCTION SomeStuff( _
                    var1 AS LONG, _
                    var2 AS LONG, _
                    var3 AS LONG _
                    ) AS LONG

FlagWhiteSpace - Flags extra white space lines

RemoveFlaggedItems - Removes special commented source code lines. Special comment characters are "''//". Allows the user to clean up excess flagged items within the source code.

Some REPORT tools that output an OBNOXIOUS COMMENT message (of course) within the source code.

EmptyProcedure - INFO - Reports procedures containing no source code.

UnusedArgListVars - INFO - Reports variables listed in the procedure argument list, but never actually used.

InvalidFunctionReturnDataType - ERROR - Reports an Invalid Function Return data type.

...More to come.

We should include author credits in VB2PB's about box when we release.

Absolutely.

[John R. Heathcote]

Stan,

Just one more quick thought on Tools.

Since most of these tools will be used infrequently, when compared to the converter, I would suggest that they be located in a pull down menu as is common for most editing applications. I have included a menu header called "TOOLS" in the main editor menu so we can add whatever utilities we want. I think this would be more palatable for the user than having a bunch of command buttons floating around cluttering up the works.

Just a thought.

[Wayne Suite]

Let the user select the tools to be included during install

Since everyone has their own preference for editors etc. why not allow the user to include/not include and/or customize the tools on the toolbar in the menu.

Example: Why force POFFS, to be installed when most users developing programs already have POFFS available in another directory. I for one use SED 1.17 and have customized the tools I don't use and replaced some of them I would never use with an ASCII Chart etc.

The best way would be to give the converter the intelligence to look for these tools in sub folders of the directory where the converter is installed and then when it finds them configure them to be accessed from the tools/menu bar in the converter. Also similiar to SED allow the user the options to edit the tool/menu bar to include/exclude the items according to his/her preference.

[Rodney Hicks]

Since everyone has their own preference for editors etc.

And since all these people are programmers, and since this is going to be open source, why should we accommodate any other editor but PB. If an individual wants to use Billy-Bob's editor, let him make the necessary changes to the code. We cannot be all things to all people.

I bring this up merely because the thought of us spending time on PowerBASIC Inc.'s website to create an application that goes out of its' way to make it possible for users to use other editors makes me uncomfortable, especially when PowerBASIC provides the editor that is most specific to writing code in PB.

[John R. Heathcote]

Since everyone has their own preference for editors etc. why not allow the user to include/not include and/or customize the tools on the toolbar in the menu.

We may do this in the future, but for now there are tools that would be handy for conversion purposes.

Example: Why force POFFS, to be installed when most users developing programs already have POFFS available in another directory. I for one use SED 1.17 and have customized the tools I don't use and replaced some of them I would never use with an ASCII Chart etc.

You may be assuming a lot. There was a recent thread in the PB forums where a user wanted know if there were some form of on-line documentation other than what PB supplied. They were directed to POFFS. The user didn't know what that was. Honestly, I would be totally lost without POFFS. POFFS is what the online PB documentation should have been.

I use SED myself, have customized the tools, and I am quite satisfied with it.

Perhaps we could allow the user to pick and choose what utilities and tools they would like to install during the installation routine.

The best way would be to give the converter the intelligence to look for these tools in sub folders of the directory where the converter is installed and then when it finds them configure them to be accessed from the tools/menu bar in the converter. Also similiar to SED allow the user the options to edit the tool/menu bar to include/exclude the items according to his/her preference.

A nice idea, but I'm really not looking forward to reinvent the wheel with our editor. Why should we? The main purpose of our editor is to supply the user visual feedback of the conversion process. In that respect our editor does something no other editor is able to do.

[John R. Heathcote]

And since all these people are programmers, and since this is going to be open source, why should we accommodate any other editor but PB. If an individual wants to use Billy-Bob's editor, let him make the necessary changes to the code. We cannot be all things to all people.

I tend to agree with you Rod.

I bring this up merely because the thought of us spending time on PowerBASIC Inc.'s website to create an application that goes out of its' way to make it possible for users to use other editors makes me uncomfortable,...

Not to mention that it is outside the intent (and maybe the scope) of the converter project.

... especially when PowerBASIC provides the editor that is most specific to writing code in PB.

Well, I can say this issue is relative. Although the PB editor works, I personally do not think it is very intuitive, nor as easy to use when compared to some of the other editors out there, such as SED, Jellyfish Pro, etc. But this is just my opinion.

[Rodney Hicks]

Well, I can say this issue is relative. Although the PB editor works, I personally do not think it is very intuitive, nor as easy to use when compared to some of the other editors out there, such as SED, Jellyfish Pro, etc. But this is just my opinion.

Agree on it being relative. Most of the other editors were designed to mimic other qualities of other programming editors that the designer was used to using, and wanted with PB. This is not to say that there aren't some things there that I wouldn't mind having, it's just that the PB editor is the only one that we know for sure is going to do the right thing with the code we produce.

[John R. Heathcote]

Rod,

Agree on it being relative. Most of the other editors were designed to mimic other qualities of other programming editors that the designer was used to using, and wanted with PB.

I happen to believe there are some important user issues to consider as well.

For example, the SED editor uses a tab control to allow the user to switch between MDI forms, for me it is far more convenient to click on a tab than to constantly press the F2 key then click on the procedure I want as in the PB IDE. In SED you can also create a project of all your modules in a TreeView control and double click on the file you want and presto its loaded for you and made active. This is really handy if you have a lot of files loaded at the same time.

While the PB editor has some of the functionality I previously mentioned it is not as easy to get to IMHO, and as I said before, it is not intuitive for me to use. I'm a firm believer that the design of the software should not hinder your ultimate processing goal. I like functionality and options to be presented to me up front without my having to dig around, or mouse around, clicking on controls and menu items, to try to find the options/commands I want. Again, IMO the PB IDE forces you to hunt for commands/options while SED does not.

My point is the PB IDE could be easily upgraded to address these user issues too, heck, the PB team even shows you how to do it in the \Sample source code examples provided with your PB 9.0 installation. In defense of the PB IDE I am willing to state that I prefer the SED editor over the PB IDE in developing source code, so I do have a natural bias.

...it's just that the PB editor is the only one that we know for sure is going to do the right thing with the code we produce.

Agree 100% with you on this issue.

[StanHelton]

Interesting points all around. If my impression is correct, most VBers will want some of the features provided by such 3rd party tools as JellyFish and SED. That's the main reason I think we should include some of the smaller, occasionally useful tools in the distro (with author's permissions). We could also include demos of 3rd party products and/or links to the websites.

Actual integration of 3rd party tools should be put back to the second release of VB2PB. The fact that we are open source and many of these tools are not is a stumbling block for some 3rd party authors. This may have the effect of limiting "integration" to a SHELL out to the tool and then trying to use the output in VB2PB.

The issues get complex. I suggest that for now we focus on tools and/or demos that are useful (even if only rarely used), but not integrated.

[Rodney Hicks]

The issues get complex.

That they do, and I'm trying to keep our focus narrow for the first version. Screening feedback will give us good direction on what tools to accommodate, what features to improve.
We need that feedback to make the converter a good successful endeavour. Our first should only be bare bones to get the feedback started. We are too small a group, not entirely representative of the prospective users, to know all the proper animals to let infiltrate. Users with entirely different programming needs from any of us should benefit as well from this converter project if the project is to be a success. Further, at least for the time being, any cost(user cost) incurring programs, tools, etc. should be latered to see if they are required at all. I'm not sure there are any of those, but it is a starting point for leaving them out of the loop for the time being.

[John R. Heathcote]

Rod,

Screening feedback will give us good direction on what tools to accommodate, what features to improve.

So true, agree 100%.

Further, at least for the time being, any cost(user cost) incurring programs, tools, etc. should be latered to see if they are required at all. I'm not sure there are any of those, but it is a starting point for leaving them out of the loop for the time being.

For the most part I concur, but the exception is generating dialog boxes from VB code. This has to work in Version 1 IMO.

[Rodney Hicks]

but the exception is generating dialog boxes from VB code.

Is there any way that we can trick Murphy into handling these?

I wonder, just wondering here, throwing out a thought. Can we glean from the VB code via the converter the necessary parameters for the dialog boxes that would allow use of the new DISPLAY [BROWSE|COLOR|FONT|OPENFILE|SAVEFILE] statements. I think that if we were to allot default parameters for most of the parameters, and either glean the info from the VB source code or request user input (NEEDINPUTFROMUSER1).
This might work for these specific dialogs, which will be the most abundant.

[Rodney Hicks]

Doing some more thinking on these dialog boxes.

Do dialog boxes show up, that is, get created in the *.frm files? If not, where?
I know that there are a host of others, Print Dialog, Connection Dialog, etc that aren't included in the DISPLAY xxxxx group. Are all dialogs created with the VB version of DISPLAY xxxx as in, forgive my terms here, Dialog.Openfile kind of thing outside the *.frm file manner? If so I can also see reason for concern, but if there is a mountain, it's there to be climbed.

Coming at the issue from a different direction, I wonder, is it not likely that these are COM objects or some such terminology. Do they exist in an accessible Library, or would we have to create one? I warn right now I'm not sure about what I am asking here.

Boy, I got a lot a learnin to do. All over again.

[John R. Heathcote]

Rod,

Is there any way that we can trick Murphy into handling these?

Not without an official title he won't. What would you call him? MINISTER of MURPHY?

I wonder, just wondering here, throwing out a thought. Can we glean from the VB code via the converter the necessary parameters for the dialog boxes that would allow use of the new DISPLAY [BROWSE|COLOR|FONT|OPENFILE|SAVEFILE] statements.

Yes, I think this is doable. In order to handle the VB conversion files at a project level as part of the editor I'm having to delve into VB project and definition requirements to glean the files we will need for immediate conversion. What I've found so far is encouraging, unfortunately, the information is not located in one place, but it is there.

I think that if we were to allot default parameters for most of the parameters, and either glean the info from the VB source code or request user input (NEEDINPUTFROMUSER1).
This might work for these specific dialogs, which will be the most abundant.

For the first version of our converter I think this is the way to go. We have so many technical issues to solve here that get right to the heart of the functionality issues we face in the conversion process. So if you all will forgive me, the sexy color you used in your dialog box is last on my priority list of things to do.

I think we have to approach the conversion of dialog boxes from the standpoint of default colors, fonts, etc. I know this would tend to take out some of the flashy aspects of the VB form, but right now I'm more concerned about preserving the functionality of the dialog box in the PB conversion. I happen to think generating the correct answer is more important than color.

Do dialog boxes show up, that is, get created in the *.frm files?

Yes, the data that defines the dialog box is included in the .FRM file (width, height, Left, top,etc.) in addition to the controls that appear on the form, the references to the dialog box (what dialog box to include in your VB project) is stored in the .VBP file. The information is there we just have to go after it.

I know that there are a host of others, Print Dialog, Connection Dialog, etc that aren't included in the DISPLAY xxxxx group.

If I remember correctly, and the VB gurus please correct me if I'm wrong, but the above dialogs are part of the preprogrammed bunch of system dialog boxes that you can access without having to create them. In VB you simply attach a reference to them in your VB project and you can begin using them in your app.

Coming at the issue from a different direction, I wonder, is it not likely that these are COM objects or some such terminology. Do they exist in an accessible Library, or would we have to create one? I warn right now I'm not sure about what I am asking here.

Nothing ventured, nothing gained.

I think the dialogs like Print, Connection, Open, Save are included in the "comdlg32.ocx" and I think you do access them via COM. I see no reason why we couldn't do the came in the PB conversion code.

The user defined forms are another matter. Since they are unique, I think VB creates the COM references to them on the fly. I say this because I am unable to find a GUID for them, not that it doesn't exist, I just haven't found it yet.

Boy, I got a lot a learnin to do. All over again.

Me too.

[Rodney Hicks]

Your analysis of my analysis makes me feel better about how I'm thinking about this.

I left the user defined out of my analysis simply because they are going to run the gamut on us and are going to take some detective work by the converter to get them to function, and I was aware of this aspect, but there may be hope with that yet, for even VBers didn't always try to reinvent standards and things with each iteration of some dialog. It's just that each had their own inventions.

I'm out of town for a couple of days again tomorrow.