It will be late in the year before we release a totally new SF 2.0.  We want to make sure that there isa  migration path and there is a LOT of new stuff that we want to do including more RAD and web components, etc.

SF 2.0?? Cool. When?

________________
_____/ Regards,
____/ al

Good dialog, guys.  If you look around the forum, you will see that this debate has come up more than once and we have mentioned that there will be most of what you are requesting in future updates.  The goal is to get away from data queries...this would be slow and unresponsive the large the app became.  But we have some ideas that we feel will be beneficial to everyone and still make it easy to make changes.  This will not be implemented until SF 2.0, however, when we rewrite all UI controls.

That is indeed correct but it is important that the tool or suggestion is in fact a benefit to the overall community. My point is that VPME is not as wonderful as some posts in these forums would suggest and I would choose to argue that point in the hope of preventing SF from becoming a .NET version of VPME - which in my opinion is not in the interests of the overall community.

I am here because I became fed up with VFP/VPME and consider .NET/SF to be light years ahead in comparision. That doesn't mean I don't want to see SF evolve as I very much do.

I am not trying to force my views on the SF developers but I will argue my corner if I believe other products are being held in comparison to SF unfairly.

Hi guys!



I don't want to get into a long debate on this, and I cannot comment specifically on VPM's strengths (or weaknesses) as my VFP framework experience is based on VFE and a custom-developed OOP framework.



My experience with both those VFP frameworks was similar to Edhy's. I found the experiences very positive, allowing the development of strong, scalable, and maintainable applications much quicker than otherwise possible. I have to say that unlike both Aaron and Edhy, my experience with the VFE Data Dictionary was incredible--the ability to objectify data (down to the field level) and control behavior using custom field behavior classes, identify lookup and validation at the data layer independent of the UI, and introduce custom behavior via exposed hooks was powerful stuff. The fact that the Data Dictionary also allowed for dropping controls and labels on forms that auto-bound to data dictionary properties and eliminate the need to update labels with "Customer Address" hundreds of times in every form in an app was even more icing on the cake.



I agree with Edhy that to the extent that builders and other goodies can facilitate and quicken delivery of applications, MF should consider adding them to the great framework known as StrataFrame. I would image such improvements need not require a developer to use them, allowing them to "roll their own" if they have the time and inclination. Choice is a happy thing, right? There should always be the flexibility of each developer to map his or her own approach to solving business problems, but to categorically discount tools found helpful by others based on individual preferences or experiences may not be in the best interest of the overall community.



Now if you'll excuse me I've not touched StrataFrame yet today so I really need to get back to some fun stuff!



Have a good one!




________________
_____/ Regards,
____/ al

Hi Edhy,

I am glad your experience of VFP/VPME is the reverse of mine but I stand by my comments and, quite frankly, I could expand on them. I am afraid I worked on a large VPME application containing around 450 forms over a period of several years and it was not easy to maintain and form building was a real pain. Re-writing the same application in SF was a joy in comparision and the form building was very fast, powerful and appealling to the end users.

However, I have just realised I am talking about VPME in the SF forums and I would much prefer to talk about SF and to totally forget about VPME so I will retreat into silence

Aaron

Hi Aaron,

I do agree with you in many things, but this thread was not about making a comparison between VFP & .NET frameworks and specifically with Visual ProMatrix (VPM) which is the one I used and continue to used to support some project that have not been upgraded to SF.

The whole point is to have a better RAD tool, and to do so, there are some other things used in VFP and other .NET frameworks that would help speed up the repetitive process of creating forms.

I am very thankful to VPM and the ProMatrix corporation for the time invested in trying to keep VPM up to the current technology, and frankly my experience with VPM is the total opposite of yours also I know many developers that are coming from VFE and VFE had much more builders and goodies than VPM and are now using SF.

I also don't miss the data dictionary, but there are many information in the SF BOM and in the DDT metadata that could help us create forms much faster with less error like having to manually set the MaxLengh or the InputMask properties all over a field is used, this information can be carried away from the DDT or the BOM into the business object and does not require to ship any metadata to the customer.

In my case, I work with several small projects all the time and would greatly benefit of any help from the framework to make me more productive in less time.

Edhy Rijo

Sorry guys, just wanted to add my two cents here. I also came from a VFP/VPME background and I would definitely NOT want their form builders in SF. I have no doubt that SF builders would be better implemented but I have definitely found that building forms in .NET/SF is MANY MANY times faster than VFP/VPME. I enjoy the freedom and the speed of form development in SF and I have much greater productivity than in VFP/VPME. The visual impact to the customer is hugely superior and it is all achieved with considerably less work - of course that may not be reflected in the final bill

On paper a data dictionary sounds great but I don't miss it. A data dictionary that can be modified for each installation really adds great configuration options per installation - that is until you release the next version of your application which wipes the previous data dictionary and all the local user changes. Been there and sadly done that and don't want to repeat it again I don't have a data dictionary in my SF application that totally replaced a VFP/VPME application and I don't miss it at all. I have far more (updatable) configuration options now which took about half a day to write.

While the auto adding of a caption when a field is dragged onto the form would be kinda nice, it wouldn't really add much in my opinion. I typically just copy and paste similar fields from other forms and change the binding fields on the text box. I still sometimes have to go back and modify some of the screens in my legacy VFP/VPME application and I hate it. Simply adding a new column in the middle of a grid can take forever when it takes seconds in .NET.

SF is light years ahead of VFP/VPME - please don't pull it back a decade.

Sorry for jumping in and I appologise if my views are strong but I bought SF because it was not VFP/VPME 

Aaron

For what it's worth, I would like to see this as well. Coming from a Visual FoxExpress environment I agree this would be a huge time-saver. In VFE you can actually control the class for each BO/DataSource field that will be used, including specifying custom classes (e.g., a custom textbox class).

________________
_____/ Regards,
____/ al

Yeah, we have had these discussions on the forum, and we may provide this type of functionality in the future, but it will not be stored in the database.  If you have noticed, we have 3 methods of pulling localization, SQL Server, external XML, and embedded XML.  The embedded XML is by far the fastest...so this would be the type of implementation that the data dictionary logic would follow.  Pulling all of this type of information from a server, especially in a disconnected data environment, would be application suicide   To make this fast it would all have to be embedded on the client side...just like we did with the localization.

Edhy, the current version of StrataFrame is NOT the last version.  We have gathered many good ideas that we fully intend to implement in StrataFrame.  We have MANY things that we intend to add to StrataFrame...but this is not a feature that we have today.  If all software companies could come up with every idea and create the perfect software to last the ages the very first (or many) blush, then there wouldn't be maintenance releases and the "next" release.  I think that you get my point.  We plan to have many new RAD features in the future, but this particular feature that you want is not currently there....I am aware of what you want and it is on the list of future enhancements.