xsharp.eu

Hi Jeff,

Jeff Stone wrote: Anyway, back to my original question, does XIDE form generation allow me to quickly display dbf field data in a form? If so, how?

Please select Project->Create New->Application and from the dialog that opens, choose the "Standard VO Mdi" template. Compile and run it, then in the app that opens, select File->Open and choose a dbf file. If the dbf has VFP specific fields, you will need to change the code in Start.prg, from RddSetDefault( "DBFNTX" ) to RddSetDefault( "DBFVFP" )

This creates a very basic dbf standard viewer app which uses the libraries from Visual Objects. Databinding works automatically, it is implemented in those libraries. For FoxPro, there will be a similar solution in the future, which will be using libraries that emulate FoxPro's behavior, instead of that of VO's.

Then of course, you can also use Window forms, or WPF, which have their own sophisticated data binding systems, but I think this is not what you are interested it, what you need is a VF-like solution that will come in the future.

Chris - Early on after I discovered XSharp, I began experimenting with replicating the VFP UI forms and custom user controls in WinForms. I immediately saw that the VFP nested controls model (multiple UI controls in Containers, with inheritance and further customization once dropped onto an actual Form), was basically impossible to develop in Winforms. It is very rigid, and doesn't even come close to what VFP allows. I basically quit that UI exploration because I saw the gap was far too wide, at least for my little skill set.

I made videos to demonstrate the shortcomings I was running in to, I think you may have see them.

I think XSharp team has demonstrated that can handle a huge percent of the VFP language stuff, but the UI piece remains a big mystery.

Hi Matt,

Yes, I remember those videos, I had also been playing with that. Certainly using plain winforms is gonna be tricky emulating all the behavior of VFP, but it has the advantage of making it very easy to use also the thousands of 3rd controls available in .Net, inside "VFP" forms. In a custom editor we can do whatever we want and have full control over it, but makes it very difficult to use other .Net controls in the same form.

Maybe we will end up with some kind of combination of the two, or even just supplying both solutions, each one to be used when if fits best. I think we will be able to start looking very closely into it in the coming months, let's see how it goes.

Thanks to everyone for your feedback.

Chris, I did as you instructed and was essentially able to view VFP equivalents of the Edit and Browse windows which show all fields for a single record and all fields for all records, respectively. (I think these features are very important to VFP users and should be highlighted in documentation for them.) I am curious as to what I would need to do, if I wanted to create a form which contained just two of the dbf fields for a single record. Can this be done programmatically rather than through the forms generation XIDE features?

VFP forms are generally created using the .sct and .scx files where the .sct file is an .fpt file and the .scx file is a DBF file. Using the program https://github.com/VFPX/AlternateSCCText, you can pull the VFP form code. So, the equivalent of this code is what I was hoping to view for X#. I gather that .Net implementation of forms may be too different to do an apples to apples comparison. Robert, I look forward to your data binding session.

Thanks to everyone for your feedback.

Chris, I did as you instructed and was essentially able to view VFP equivalents of the Edit and Browse windows which show all fields for a single record and all fields for all records, respectively. (I think these features are very important to VFP users and should be highlighted in documentation for them.) I am curious as to what I would need to do, if I wanted to create a form which contained just two of the dbf fields for a single record. Can this be done programmatically rather than through the forms generation XIDE features?

VFP forms are generally created using the .sct and .scx files where the .sct file is an .fpt file and the .scx file is a DBF file. Using the program https://github.com/VFPX/AlternateSCCText, you can pull the VFP form code. So, the equivalent of this code is what I was hoping to view for X#. I gather that .Net implementation of forms may be too different to do an apples to apples comparison. Robert, I look forward to your data binding session.

Hi Jeff,

Thanks, we are aware of the tools to extract VFP code, forms etc, in fact Fabrice is already working on a tool that does exactly that.

Regarding the edit and browse windows, yes, it is very easy to further create a form that shows only a few fields and you can decide to either have them automatically bind their contents to the dbf fields, or write code to do the binding manually. But I wouldn't go far that route, it must be clear that what you tried so far is not meant to be used by VFP developers, it is a dedicated solution which is identical to what VO developers are used to be doing, a means of porting their apps in X# and continue editing them in the same way as they used to in VO. It's just because VO and VFP are both descendants of dBase, that this VO approach feels familiar to you. What we will do in the future is to provide a solution which will be A LOT more familiar to you, from a VFP perspective. But it will take some time to implement this.

Honestly I'm torn about this. VFP does allow you to bind form fields directly to DBF fields, but that's not best-practice. Not implementing that would force us to use proper entity objects.

I guess you have a point, but in any case I do not think we can avoid implementing a VFP compatible solution as well. Some people will will want to move to the "better" practices, but I am sure also a lot others will still want to have their apps continue working exactly the way they used to already in VFP.

I think it is clearly bad practice if you bind directly on fields of an unbuffered table used to persist user input. I have been using biz and data layers for ages, using view or cursor records instead of lists of pojos, circumventing the need for ORMs. As long as the backend data store is relational, for client side dev this is IMO the better model - on a REST or SOAP sending web server a shortlived pojo (list) makes sense for horizontal scalability, but on the client this is not needed, as there is only a single user working with the result sets. The cursoradatper/cursor with rowversion and tableupdate() is the sauce keeping me in vfp (with some data exploration on the side...) and here

my 0.22€
thomas

Eric Selje wrote:Honestly I'm torn about this. VFP does allow you to bind form fields directly to DBF fields, but that's not best-practice. Not implementing that would force us to use proper entity objects.

It is a crude, even vulgar, practice and capability.

However, it should *definitely* be implement and supported in X#.