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!

We generally get this request from VFP developers...and me being one as well I generally never used this in VFP. I move faster with copy and pastes...though I do see that this would be nice and it is already on the enhancement list.

Yes, I guess we all love VFP   I use Visual ProMatrix for many years and VPM has some very nice builders to help you out with the startup layout of the forms and drop all fields/captions properly binded so we don't have to go each one changing it.  Of course they have a data dictionary which holds the caption information an much more about each field, the builders use this info to populated all this data like:

• Caption
• ToolTips
• Message
• Minor validations like field length enforcement
• InputMask
• etc.

That is why my first impression of your BOM was that it will provide the same kind of info into the BO, and I still believe it is possible to enhance the BOM to do all this. 

TIP! I know of another popular .NET framework which has this kind of builder to populate all controls in the form and there is not need to go to every control to do the BindingField manually.

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.

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

Aaron Young (02/25/2009)

---

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

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.

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

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.