Hi All,

I have seen VB.NET videos where fields objects are dropped from the Data Source which cause a label (with the proper caption) and a textbox (usually) to be created on the form. Certainly this way save us a lot of time when you have many fields to create with many forms

I have not seen anything in SF documentation that will cover this, and I had tried dropping a field object from one of my SF business object from the Data Sources windows but it will not create the objects from the SF class, instead they will be created from the default .NET classes.

So my question would be, is there any facility in SF to help you out in this regard? or we have to simply manually drop labels, textboxes from SF Toolbox and manually change the caption and assign the BindingField?

Thanks!

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

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

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