TOPIC:

I'm continuing my testing and getting acquainted with X# and am now trying to better understand how forms/form syntax bind to .DBF variables. Since my initial testing is all using XIDE, can someone point me to sample code or a sample XIDE application that shows this?

TIA,

Jeff

Hi Jeff,
are you talking about Windows Forms Databinding?
Wolfgang

are you talking about Windows Forms Databinding?

@Wolfagng -

I bet because he is a FoxPro guy, he's trying to do that thing we all do... Trying to see how similar the new system it to the old one we know so well.

In FoxPro, if you have a UI control on a Form, there is a single property on the called ControlSource, and you'd set that to a string value that references one of two possible sources of data:
.

• Cursor.FieldName reference
• or
• ObjectRef.PropertyName

.

Matt (and Jeff),

Understood, but there are several different things you can do in .Net and X#:

1. People with existing VO apps (or who want to keep developing the same way in X#) can use the VO compatible window editor, which exactly like in VO, uses a similar mechanism to what you described in FoxPro, in order to do data binding

2. Windows Forms has it's own different data binding system

3. WPF uses a yet another different system for data binding, which is by far the most sophisticated AFAIK

4. Of course you can implement your own data binding system, which works exactly as you want it to. Myself (and a lot of other people) in VO I had never used the built in system but instead wrote something custom that works between the user and the GUI, for maximum flexibility.

5. In the future, there will be a form designer for VFP apps and developers, which will probably work in an identical way to that of VFP, exactly as you are familiar with it. Similar solution to what we did with the VO dialect, where the window editor is identical to that of VO.

So there's not really one specific way of how data binding works in X# and/or .Net. It's how you want it to work, depending first of all on the GUI solution you plan to use.

Hi Matt,
in VO we have something that is called "name-based binding". That means that you have a datasource (mostly a DBServer object or a SQL Dataset), and when you bind that to a datawindow, the controls will be bound to a field of the same name in the datasource. For example, if you have a field called "foxpro" in your window, and a field of the same name in the datasource, the binding procedure will establish a bidirectional binding. Changing the field in the window will change it in the datasource and viceversa.

Windows Forms (and WPF) are not database centric environments, so they know nothing about this. But they offer another (much more powerful, specially in the case of WPF) binding mechanism, and with a bit of generic code and a Form subclass it is possible to establish the same behavior as in VO.

I have some samples for this, both in WPF and in Windows Forms, but non of them is complete to show what can be accomplished.

Of course you can bind any value to any field als in Windows Forms and WPF, but it is a manual work.

Personally I have found it rather confusing to have a control named "Edit1" bound to a field value "artcode", and was really happy that the VO databinding has constrained us to use meaningful names also for the controls. (I had to deal with manual bindings in a Delphi project I had to maintain, but fortunately I was able to pass this project to an employee that had Delphi knowledge from a former work).

Wolfgang

5. In the future, there will be a form designer for VFP apps and developers, which will probably work in an identical way to that of VFP, exactly as you are familiar with it. Similar solution to what we did with the VO dialect, where the window editor is identical to that of VO.

Chris - ok, this i new news, it seems... Last I understood, WinForms was going to be the target for migrated VFP apps. A dedicated VFP form designer, is, well... I'm snot sure what even to say. Welcomed, I believe, especially it is a LOT like the VFP form designer. But, man, it seems like a TON of work. And underneath of it, what is really there?

FoxProMatt wrote:

5. In the future, there will be a form designer for VFP apps and developers, which will probably work in an identical way to that of VFP, exactly as you are familiar with it. Similar solution to what we did with the VO dialect, where the window editor is identical to that of VO.

Chris - ok, this i new news, it seems... Last I understood, WinForms was going to be the target for migrated VFP apps. A dedicated VFP form designer, is, well... I'm snot sure what even to say. Welcomed, I believe, especially it is a LOT like the VFP form designer. But, man, it seems like a TON of work. And underneath of it, what is really there?

Is it really news? Haven't we been discussing this for quite some time publicly about providing a way to edit forms in a VFP-similar way? There was even a thread in Foxite asking about people's opinion on this..

OK, a directly compatible to VFP form editor is only on of two most likely solutions, the other being adjusting the standard WinForms editor (with control subclassing etc) to bring it closer to that of VFP. Both solutions have their pros and cons, still not sure which path we will follow at the end, my personal view is it is more likely we will need to do the completely custom one. Doing both is another option of course...

Matt was kind of correct in that I'm looking at X# from a VFP user's perspective. I was just trying to understand how quickly using XIDE I could display .dbf fields in a form. I didn't see any mention of this in the XIDE Help pages nor did I find a video demonstrating this either; hence my post. FWIW, I have also converted a number of our VFP forms in Harbour MiniGui which can be done with just a moderate amount of effort.

To attract and keep VFP users, I think it's helpful to start them off with an interface experience that is somewhat similar to what they are used to. My initial impression is XIDE is far closer than VS. While I haven't played with XSI.exe yet, I was thinking that if it were embedded in XIDE, it might function like the VFP command window. This experience should be coupled with a simple tutorial of XIDE that shows the basic elements of using X#. (Eric Selje's article at saltydogllc.com/wp-content/uploads/SELJE-Look-at-X-Sharp.pdf might be a good starting point for VFPers even if the article is already slightly out of date.)

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

TIA,

Jeff

Hi Jeff,
if no one is able to have an example, I will try to do one. But first I have to play with the VFP view of data.
Wolfgang

Jeff,
I am preparing a session about Data Binding in .Net for Virtual Fox Fest.
Unfortunately I do not have the X# VFP part ready yet, so I cannot upload the example.
But that should be ready in a week or two.

Robert

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 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 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#.