Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Ad hoc report writers
Message
From
16/06/1999 12:35:42
 
 
To
15/06/1999 21:49:41
General information
Forum:
Visual FoxPro
Category:
Third party products
Miscellaneous
Thread ID:
00205604
Message ID:
00230488
Views:
29
Foxfire! 3.5 still utilizes Fox 2.6 SPR's for the interface. However, this new version won't be released for Fox 2.6 developers. There is quite a bit of VFP specific code in this new version. For example, one of the biggest improvements is the new Join Builder engine. To make it possible to build SQL using the Sql-92 join syntax, you now specify join relationships using a Tree metaphor. You now can graphically define the parent-child relationships and 1-many direction of each join. This is done using a Treeview control. "NAME'd" SPR's behave as FORMS, so we use many VFP only controls throughout the interface, and refer to them in code using the usual dot syntax.

Also, we have begun using non-visual classes as much as possible where appropriate. The ODBC connectivity in the 3.5 Enterprise version in maintained using a "odbc connection" object. The code throughout refers to this object to test and maintain the Sql connection.

Just one more thing... we've added the ability for you to specify a specific VFP user-interface control for each item in the data dictionary. The idea is that when users are building a Filter, such as "customer name is like ....", the UI control in which they enter the filter value can be inserted at run-time from your UI class hierarchy. Therefore, if you have standard textbox or combo boxes that you use throughout your application interface, and you want your trained users to be able to see those same UI controls within Foxfire!'s filter builder, you can. This feature came about due to one of our customer's, Remarketing Services of America, who had an extensive UI control class library, and didn't want to "lose" all the cabability within Foxfire!. Given that the Filter Builder is where most users spend the majority of the time in Foxfire!, then you will have the full power of VFP's object model in that critical area.

In regards to any problems running SPR's in VFP... we have many customers running without problems using Foxfire! as an integrated part of their application. The before mentioned RSA just was a finalist in last week's DevCon Excellance Awards for their application, which makes extensive use of Foxfire!.

Nevertheless, we are well into development of a completely rewritten object-oriented version of Foxfire! We have spent the past 12 months working with our customer base to address some functional limitations of the 3.0 version of the product, and that will manifest itself as version 3.5. The next version will definately be written as components, using VFP 6.0, and will ship with at least two separate interfaces, one for VFP developers, and one for VB developers. This is made possible due to VFP's ability to create COM objects, which can then be accessed by any COM compliant development system.

Please send me shipping info if you are interested in a beta copy of v3.5.

Thanks,

Bill
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform