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

This has been requested in the past, and I guess I see how it could be pretty handy.  At some point we will add the ability to open up a form designer from the BO dropped on the form and drag fields onto the form.  This, however, will also mean that we will need to have a maintenance area to allow you to specify those definitions (i.e. SF textbox for String, etc). .NET kindof has a way of doing this, but it will not set the SF binding properties.  If you open up the Options and go to WIndows Forms Designer and UI Data Customization you will see how to set this.

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.

Edhy Rijo

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.

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

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

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

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.