automatic PB "form" creation

[Chris Holbrook]

I would like to make "forms" i.e. programs with source code editable using PBForms, driven from a data source like a text file or something of the sort. The data source would have data and screen names, types and formats for each "field", each of which would result in, say, an editbox control. Obviously this lends itself to development.

I can't (to my surprise) find anything on the forums, any suggestions welcome!

[Rodney Hicks]

If you're thinking what I think you're thinking it is an idea that has merit, but only as long as you aren't trying to reinvent the wheel here. If you're trying to invent a tire for the wheel, it may work, but there are lots of issues.

Correct me if I'm wrong:

When I begin working on a program, I use a simple text editor to describe the program, sort of a text version of a flowchart, like so:
I want a window with a menu, text box, three buttons, ..
The menu should have four main elements...
The text box should be located at...
The three buttons should be labeled "Accept", "Next", "Quit",.....
etc....

These documents get quite large as I move back and forth making sure that details are correct.
Is this the kind of text file you had in mind?

[Chris Holbrook]

Rodney, I was thinking of generating a form from a description of a database table. Then I could run the application for each table in the database where it made sense to have a maintenance or review form. The result would be forms which could be tidied up using PBForms. Poor man's RAD. The optional components which you mention could be useful too though I don't have a data source for that information and had thought of adding it at the PBForms stage. It would be useful to have a default listview which shows all columns of the table, which could use screen names as column titles. Extracting the DDL from the database would be fairly straightforward, and could at least for testing purposes go via a text file.

[Rodney Hicks]

I now see what you're after and I know not of anything like that offhand.

Darn!!

[Michael Mattias]

Why bother with PB/Forms to 'tweak' your screen?

Can't you just read your screen specs from your database and create screens something like..

 DIALOG NEW  0, sText1, Xpos, Ypos, cx1, cy1...
 CONTROL ADD BUTTON hDlg, sText2, xpos2, ypos2, cx2, cy2....

... where sText1, sText2, xpos1, ypos1, cx1, cy1 etc are read from your specifications file/database before you start this sequence?

You can use a 'design tool' to get the intial values to store in your specifications files.

Actually sounds to me like you have a NFS for PBForms: Support variables in generated code for dialog and control creation, not just numeric literals. (and/or equates, which might already be allowed?) (I'm not a PBForms user so I don't know if that's supported).

MCM

[Chris Holbrook]

Why bother with PB/Forms to 'tweak' your screen?

I suppose I should first state that my approach is more in the nature of a raiding party than a planned campaign. I've used CASE tools in the past and recently I evaluated a couple of RAD development environments, needing to do some work on Windows. If I am to persevere with PB, I will have to become a lot more productive with it. PBForms is a bit minimalist by current standards, it would be rather good if one could also open a database, select a table, and assign column values to controls, and even better if one could attach code to these controls' events - but that's not the PB model.

So instead I thought I would write an application which enabled database and table selection, and created a form as source code, containing say, a listview populated from all columns of the table, and one textbox per column, as a sort of template to which other controls could be added and the automatic ones cleaned up using Forms, launched by the new application after compilation. Thereafter, extra functionality added in the IDE. The point is, I can get to template stage with just a couple of clicks, and the application will have all the database-handling code and variables as well as the form itself. The database tells me about the data design, not about the form layout per se, although data types will predict default formatting for the screen, which can be changed later in the IDE as required.

So my first job in developing a new appication is database design, then template creation (this bit), then reworking of the templates into viable application components. Of course, doing it this way will result in a lot of executables.

There will be plenty of scope for refinement both in presentation (formatting, e.g.) and logic (extracting foriegn keys from the database in order to bring in rules tables, e.g.), but let me not get ahead of myself -even though it's my natural habitat...

[Rodney Hicks]

The idea to send in a NFS is a good one, and if you were to send in a NFS you would be at least the second.

I sent the following some time ago:

18)Similar to placing an Icon in the Caption box, a method of inserting a variable(or array element) without having to leave PBForms. This might require that PBForms also DIM the variable somewhere in the generated code.

I wasn't too specific with my request figuring that they would know better how to implement such, but your requirement would give them a very good example of programmers needs(wants).

That was a very good connection for someone that doesn't use PBForms! I do and I missed it.

[Michael Mattias]

>That was a very good connection for someone that doesn't use PBForms

As I've told Mr. Knoppert on several occasions, that's why I get the big gilders.

[Rod Gobby]

I can't (to my surprise) find anything on the forums, any suggestions welcome!

You have the right idea! For almost 40 years we've used in-house code generators to take some of the tedium out of coding. The concept works very well.

In it's current manifestation, our in-house Data Dictionary package allows us to specify such things as program type, file structures, form layouts, data entry edit rules, etc, etc. From this database we are then able to generate code in a number of languages: MASM, COBOL, VB and several other BASICs.

The generated code is fully functional and requires little or no manual code. But if custom code is needed, it can be entered into the data dictionary as pseudo-code and linked to the appropriate area.

At one time we used to support SPS, Autocoder, and PL/I, but there's not much call for those languages these days.

This all started in 1968 when, as an IBM systems programmer, I used the Assembler macro facility to generate quick and dirty source code. Now, our DD package runs to almost a million lines of generated code and spits out code for entire packages. Needless to say, the DD package is completely self defining, and exists only as specifications within itself.

Rod

[Chris Holbrook]

I'm pleased to announce that the approach outlined above works, and is fast enough to give me confidence to develop it further.

[Paul Purvis]

I have a question to Rod or anybody else.

Is it what you are looking for is a dynamic screen input builder routine for a program where it reads data that defines input for variables and many sorts of properties for those variables; variable name, type, range, length, location on screen, acceptable input,etc.

I was interest such a thing. I did something like that for a dos program that never got good off the ground because i did not see the internet coming into being, which you reading this proves it did.
The program was going handle listings of real estate properties.
If i knew then what i know now, i would be so rich now, i would not have any friends now.
paul

[Rodney Hicks]

Not really looking for anything. Years ago, when computers first broke the 640k mark, some pundit predicted that programming languages would have so much more capability that a person could write a program using ordinary English. Unable to tell the future as inaccurately as the pundit, I thought is was a good idea, and began to write in ordinary English what I wanted of my programs. I got so used to it and pretty much forgot about the predicted language that never came to pass.

The only thing is, I now essentially write it twice. Once in English which forever after sits idle, and then in PB(Win or CC). The PB work goes a lot easier because I've ironed out a lot of the kinks before I get started.

I still think about that 'ordinary English' compiler now and then, but I think it would be a daunting task for a solitary soldier. However, at times I think it might be possible to write something that would convert my 'prose' to a PB language .bas file and keep myself in good stead with a proven product.

Thing is with each program the need to reorder my thinking becomes a little less as I become more familiar with the tools I'm using and just being able to write the program would mean I didn't need it. Thus such a program has very low priority for me but if someone else wants to play with it, it wasn't really my idea in the first place.

Rod

[Chris Holbrook]

Is it what you are looking for is a dynamic screen input builder routine ...

Sort of, but it is driven by the standard description of the data contained in the database, that is, column names, data types & sizes, indexes and foreign keys. This is used to create some source code by specifying a number of controls, add standard code blocks, and set certain literal values. This source code which is then passed to PBForms so that the screen design can be optimised, superfluous controls deleted, new controls added, colours changed, images added, and so on. PBForms already does all that so I don't have to write it. If you make no changes to the form then you can have a new application in the relevant project directory with all the controls built (including a Listview from which any row in the table can be selected) in about 30 seconds, including the time it takes to identify the database and table. Just to emphasize the point - it is only of interest to someone using PBWin, PBForms and a RDBMS using SQL like SQLite, MySQL, Oracle, (there's probably about five of us in the universe!) and I don't put any additional metadata in the database.