Button class

[radimpl]

Hi Chris,

I sent you an email. Please answer me.

Radim

[Chris]

Hi Radim,

Will do, but I am swamped with other things at the moment, and creating the sample you requested needs some time. But then again, maybe someone else has one already, so let's give you a quick answer here and somebody else might respond sooner:

About what to use for GUI, standard winforms from scratch or implement the XBase++ GUI functions and classes with underlying Windows Forms controls and about still using the XBase++ syntax or the more clean X# one, it's completely up to you. Personally I would prefer to avoid having to make changes in my existing code, so I would choose the way of keeping the old syntax for the existing code and for the GUI and after the port of the app is complete, I would start using directly X# syntax and new standard WinForms for new stuff in the app, or even slowly replacing some of the old code with new (it's absolutely no problem mixing old and new style in the same app). But that would be my personal preference, yours might be different, so I'd suggest to research and test a bit more with all options and decide what suits you best.

In any case, yes of course X# development is (VERY) active, we are fixing problems and implement new functionality literally every day. The SQLRDD is a relatively very new development aspect of X# and will take some time to fully implement. It's just a matter of priorities and available time, what most X# developers (subscribers) request the most takes the highest priority.

Regarding data browser controls, I'm sure porting the one you are already using is doable, I just don't know how much effort it would require, before seeing the actual code. If you want to use already existing controls, there exist many options, like using the built-in in .Net DataGrid or DataGridView controls, or some 3rd party browser control, like the very sophisticated ones that come with the Infragistics or DevExpress control suites.

As for a sample, you can create a new Win Forms app in VS, drop a DataGridView control on the form from the toolbox and you can start experimenting with its functionality. For filling the table with data from a dbf, you'd need to create a DataSet object, populate it with standard dbf reading code and assign the DataSet to the grid control and it will automatically display it.

If anybody following this discussion already has such a sample, can you please share it for Radim to have a quick look? Thanks in advance!

[wriedmann]

Hi Chris, hi Radim,
this is very simple Windows Forms application that shows a DBF in DataGrid:

WinformDBF.zip

(4.19 KiB) Downloaded 74 times

This file is a XIDE applicatication export file - no VS.
I have several samples, and maybe I have to polish and document them and put them somewhere.
Wolfgang

[Chris]

Thanks a lot Wolfgang! I had forgotten this sample is already delivered with XIDE, as a sample application template.

I have produced also a VS project for it, using the XBase++ X# dialect, for Radim (and anybody else interested) to have a look:

WinformDBF_XPPDialect.zip

(13.73 KiB) Downloaded 70 times

[radimpl]

Hi Chris,

Thanks for sending the example. I will immediately wonder about it.

How do I pay half-yearly support?

As you said that it is probably better to start not modifying the XPP code and only ensure its migration under X#, so I really don't see now?
Isn't it better to immediately write everything in WinForms?
What do you think will be faster? My XPP browse has 10k lines.

Just put the pros and cons once more and I'll make a decision according to you.

Radim

[Chris]

Hi Radim,

How do I pay half-yearly support?

See here: https://www.xsharp.eu/store/shop/FOX-Su ... -c82913713

As you said that it is probably better to start not modifying the XPP code and only ensure its migration under X#, so I really don't see now?
Isn't it better to immediately write everything in WinForms?

If you look closely at the sample I sent you, it does use Windows.Forms, it just also uses an intermediate layer to translate XBase++ GUI classes and functions to Windows.Forms controls, but the test application is a pure Windows.Forms app, meaning that you can enhance it from then on using pure windows forms controls and windows (regular or 3rd party) if you like, exactly like you would do if the code was rewritten to not use at all your existing code with XBase++ GUI functions, but directly Windows.Forms controls instead.

Doing it this way (with an intermediate layer to translate XBase++ GUI to Windows.Forms) will save you the time of rewriting very large parts of your existing code. Of course the disadvantage is that you will need to put much work on enhancing this intermediate layer, to support more controls and features of the XBase++ GUI that your application uses (in the version I sent you I implemented only Buttons, Labels and Image controls). How much work this will require depends on how many different GUI features you are using in the XBase++ application and how complex those are. Only you know the details of the code of your application, so unfortunately I cannot help you more about what decision to make.

What do you think will be faster? My XPP browse has 10k lines.

Just put the pros and cons once more and I'll make a decision according to you.

Again, it depends on the actual code. Porting a 10k lines control sounds indeed a lot of work, but if the code uses over and over the same not too many GUI functions for painting etc, it might not be that difficult after all. What are you using in the browser control code, only standard XBase++ GUI functions, or do you also use direct Win32 API functions?

Also if most of those 10k lines of code are for manipulating data with standard dbf functions, then it will be easier, as most of this code should compile with no changes (or small changes) to X# directly and only the GUI specific code will need adjustments.

I hope I answered your questions. But I think the best way is for you to spend some time trying both alternatives and you will see in practice which suits your application more and then make decision based on your experience with that.