haha... something is up...

[Steven Pringels 3]

Cool.. a new forum... this time DDT

This can only mean that something must be boiling in the PB kitchen and I bet you the budget deficit of Belgium that it's an upgrade of PB Forms...

Eagerly awaiting this gem...

Cheers

stevne

[Brice Manuel]

I love DDT, and it is nice to have a DDT forum. Thank you PB team.

I haven't bought PB Forms yet. Running out of things to hock to raise the $$.

[Volker Butzlaff]

PB Forms...

...I'like PB Forms very much, because i'm a very "lazy" programmer.

It leads to huge productivity gains in my development processes using PB/Win!

bye,
Volker

[Richard Angell]

Actually, with 8.0 through 9.0 DDT has been expanded with many PB BASIC statements and functions now for some of the more powerful controls, e.g. Graphic, Listview, Treeview, StatusBar, Toolbar and Tab controls. But also we have the Graphic and Printing toolboxes that compliment these as well, Added to this are the many new additions in 9.0 to PB BASIC for our general programming needs. So this forum makes a lot of sense, just like the added forums for Assembler and COM, so we can get right into the crux of specific issues with a more precision in these areas than before, Thanks for listening PB.

[Fred H Meier]

There are many things to like about PBForms, but two of my favorites are:

1. There is no Project nor Form(s) file. Everything is inside the Bas
file. Therefore if I change size or position in the Bas file and PBForms
is also updated. Please don't change this concept.

2. The dialog/interface is very, very user friendly and easy to understand.

I too will be looking forward to an upgrade.

[Richard Angell]

"1. There is no Project nor Form(s) file. Everything is inside the Bas
file. Therefore if I change size or position in the Bas file and PBForms
is also updated. Please don't change this concept. "

This concept is fine for small utilities, but on much larger programs it can become a quite unwieldy. This is when you have many,many controls on a form and many,many forms. E.g. a current project has 160 controls on one of the main forms and that many or more on another, with many special purpose form dialogs to boot. I know of folks that have had forms with 100's more controls than this.

The point is that there are apps where another complimentary approach would be highly desired by users, like myself, with such needs, versus the all in one. Then forms could be in included .bas or .inc files identified by a PB project file which is even now available in PBWin. Updates though would remain relative to the the current schema for update and change ... in the files where the forms code function and callback reside.

This would not need to eliminate or preclude the way we currently have, where all forms are in one .bas file. But it would also allow project navigation in the PB-Forms handling to accommodate projects of any size. That would be my suggestion ... reiterated from long ago.

[John R. Heathcote]

1. There is no Project nor Form(s) file. Everything is inside the Bas
file. Therefore if I change size or position in the Bas file and PBForms
is also updated. Please don't change this concept.

Personally, I would like to have more control over this aspect of PBforms, possibly as a user defined option.

Richard makes some very valid points concerning large applications, to which I would add, that some of the functionality of PBForms needs to be rethought even for small projects. For example, PBForms needs to be more thorough in the way it adds and/or removes code from your project. It is easy to add/remove controls when in design mode, but it also forces you to design a complete dialog up front first. Once you begin to add code to your CALLBACK (a natural occurrence in the development cycle) and wish to add a new control, PBforms will add the new control to the Dialog_Show() function, but does NOT add a reference in the Dialog CALLBACK function.

PBforms does not allow users to define their own individual control callbacks within the design environment as it takes out these source code references when you save your project. IMO PBForms should provide the same functionality as PBWin.

[Hedley Moses]

I would like to see PBForms more seamlessly integrated into PBWin perhaps using tab format like excel tabs, one for the code and one for the visual designer. In the current design it still feels like 2 seperate applications.

[Richard Angell]

I prefer having the separate programs versus Hedley's comment. The reason is that forms design can be more intensive than an in-the-IDE-mini-app approach. The shortlist is more than just a tool box and properties editor. It includes the ID Editor, Tab Editor, alignment tools, code import, code save as new, etc. The wish list for PB Forms is for far more than what we see now. Keeping it a separate program with good integration/interaction with the IDE would be common sense IMO for PB developing it further without delaying any IDE advances.

Also I'd have to believe it would be easier for the 2 monitor programmers to set PB-Forms to display on another screen other than the one with the IDE code view That mode of operations would be nice if one has the means and has a lot of forms to generate, would it not? Even moving between windows in the current mode of operations is quite easy. F7 is never that far away.

Having programmed many years in IDE's that are chopped into mini-windows IMO the PB IDE with its current flexibility is better than the many "info and props rebar windows" approaches. Seeing the maximum amount of real code in the IDE is a great benefit ... fast and easy to even scroll one .bas or .inc with 10K or more lines, bookmark hopping not excluded. Fact is that with the onward march in improving the Code Browser there is no need to give code viewing space up to a project tree. With PBForms separate, we don't have to give up space to a properties window either.

The primary items that I'd like to see addressed in the PB Forms/PB IDE switch is for the IDE to preserve my bookmarks (unless the code listing length has been shortened and the bookmark line is then out of scope). I would gladly take the responsibility to move any bookmarks that might need it, which is IME far less than those thad can remain the same.

But hey folks this forum is really for DDT questions, so we are wandering off topic.

[Chris Holbrook]

Seeing the maximum amount of real code in the IDE is a great benefit

I used to think that and installed extra screens but could not cope with the extra noise in my (ruined) peripheral vision, so I'm back to one. Most displays now are wide-screen which may mean that two useable code windows can be accomodated side-by-side. Or if the function under developement is rather long, maybe the screen could be rotated through 90 deg. to give more lines at a view. ISTR NVidia drivers can accomodate this.

[Richard Angell]

I have a rotatable monitor ... but my youngest latched onto it when I was using an older system ... got to get it back ...! If I had a 2 headed or more monitor situation, I'd run PB-Forms in one the IDE in the other ... if possible. And then there are the multimonitors .... 3,4 ...8 ....

[Rodney Hicks]

Or if the function under developement is rather long, maybe the screen could be rotated through 90 deg. to give more lines at a view. ISTR NVidia drivers can accomodate this.

My HP w2207h monitor is always in portrait mode, similar to two monitors stacked. works like a charm.

[Hedley Moses]

Cool.. a new forum... this time DDT

This can only mean that something must be boiling in the PB kitchen and I bet you the budget deficit of Belgium that it's an upgrade of PB Forms...

Eagerly awaiting this gem...

Cheers

stevne

hmmm no news yet from the PB kitchen

[Hedley Moses]

Also I'd have to believe it would be easier for the 2 monitor programmers to set PB-Forms to display on another screen other than the one with the IDE code view

Yep I think I changed my mind and agree with you. Having the designer separate from the IDE does make for a much versatile solution without clutter and great for a multi monitor workspace.