You gotta see this!

[Steve Rossell]

There is an interesting announcement on the PowerBASIC Home Page!

[Brice Manuel]

I will put this on my list for Santa

[Michael Mattias]

Sorry, Steve, but PowerShirt 1.0 is old news.

(So is PowerTree 1.1. When might we expect the version supporting UNIQUE keys?)

[Fred Harris]

Sorry, Steve, but PowerShirt 1.0 is old news.

(So is PowerTree 1.1. When might we expect the version supporting UNIQUE keys?)

...or a version other than black (already got several black ones that are still running good)?

[John Petty]

Sorry, Steve, but PowerShirt 1.0 is old news.

(So is PowerTree 1.1. When might we expect the version supporting UNIQUE keys?)

You mean it doesn't? Never used it myself, thought you only used slow SQL stuff. Happy to send you a free copy of mine to compare. I doubt its as fast as PB's (haven't done a major update in 10 years) and maybe not as easy to use but unique keys, fast rebuilds and reusing deleted record space etc are standard. Send me a PM if you want to try it.

[George Bleck]

Woohoo pbforms 2.0 !!!



Added: And already Ordered !!!

[Michael Mattias]

>>(So is PowerTree 1.1. When might we expect the version supporting UNIQUE keys?)

> You mean it doesn't?

Nope, you can't define an index as "unique" to powertree.

Yeah, you can support it yourself with PT (find key with PTFF(): if found it exists), but I think it would be a better product if you could define the index as unique and have the PTAdd() function return an error when you violate uniqueness.

MCM

[Cliff Nichols]

So if I read correctly (forgive me if I am mixed up)
PB Forms1.5 (prior user) needs to get an upgrade to PB Forms 2.0 (New Version, but has NOTHING to do with recent PB upgrades? (AKA Form designer has nothing to do with code upgrade?))

I only ask because "The powers that be" usually argue when I ask for an upgrade, but I do not sweat the details when explaining it to them I see the ole' "1000 yard stare"

[Egbert Zijlema]

An important issue for me is that the resulting GUI will fit in each Windows resolution and not only in the one installed on the developer's machine. Does version 2 overcome this shortcoming?

[Carlo Pagani]

Hi Egbert

Not sure how you see this as a PB Forms issue. When you application starts, you can query the resolution and act accordingly.

Typically, your application will list as requirements your minimum resolution you need (eg 1024 x 768) and you will design your dialogs around this. When you user re-sizes the dialog, you save the resulting size on exit, then next time you app starts, it reverts to the same location/position.

Just my opinion....

[Dave Biggs]

Egbert,

It seems dialog sizes above the screen size of the developement PC are still on the 'Future Features Request' list.

A related feature I would like to see would be the ability to 'Fix' the Dialog position in code so that it is not automatically changed if you should move the dialog around on the development PC during the 'building' process.

[Jeff Blakeney]

Egbert, have you tried looking for a utlity that gives windows a larger virtual desktop? I seem to remember seeing and playing with this type of thing a long time ago. If you are running your screen at 640x480 you can specify a virtual desktop size of 1024x768 and whenever the mouse hits the edge of the screen it scrolls the virtual desktop. I think it would be far easier to install this sort of thing for use with all program than it would be for PB to write the code to do that for you when using PBForms.

I just did a quick google search for "virtual desktop for windows" and I found one called GiMeSpace Desktop Extender that sounds good. I found it at CNET's Download.com if you want to give it a try.