Additional runtime functions and classes

[wriedmann]

Hi Johan,

seriously:

I have an idea, if we can make FOX really lucrative, how about everybody gaining some financial benefit based on his/her/team's contribution?

if the X# project/FoX earns really that big money, I'm sure Robert and his group will invest the money in enhancements and new functionality hiring programmers, and if you are one of them, it is ok that you will receive some money.

I don't think money should be distributed for voluntary work.

Wolfgang

P.S. I hope the X# Project will earn enough money to make it not only survive, but also to grow

[ic2]

Hello Johan,

Sorry, at least you have taken known to be known where it was previously known to be unknown.

[ic2]

Hello Wolfgang,

IMHO the best thing would be to add a new DLL (or better 3 DLLs) to the sources and the Github project, and people willing to contribute can then contribute.

I don't think I understand clearly what you propose. End users writing functions which the development team is going to add to X#?

It would be interesting to see what makes people decide to use X#. For me personally, I am far more interested in being able to work as much as I can as I did in VO (Intellisense, organization of code - including parts I realize that can never work as nicely as it does in VO) and of course the easiest possible way to convert VO to X#. Only then I consider converting more programs to X# with the added benefit of being able to realize some specific function easier in .Net than with VO. And of course, at some point in time, X# programs will be more future proof than VO programs.

I am not someone who is in a rush to change working VO code ("if it ain't broke, don't fix it") to fancier new functions like FOR EACH, delegates, data binding, Link, CASE .. Switch, etc. Not that I say that these can't be useful, but changing existing code using what the help calls "New language features" increases the chance that I introduce new bugs while the program is most likely going to work differently or better.

I wonder if other newcomers in X# share this feeling or if they want X# especially because it can do new things, like what C# can do....That would be interesting to know and could probably determine the priority of additions.

Dick

[Chris]

Hi Dick,

Since I am also a user of X#, please let also myself answer this. I don't have old VO code to maintain or improve anymore, so I only want X# for new things. Being used to using verbose languages only (started programming in BASIC, then Pascal, Delphi, Clipper, VO - also wrote a lot of assembly but for very specific needs), I can't stand writing/reading c/c++/c# code, so I am extremely happy to have a computer language I like a lot to program in .Net with!

I could possibly use VBnet instead, but VBNet does not have a preprocessor, macro compiler, both ' and " as string delimiters, direct syntax for dbfs etc. Although currently I rarely use those features, as I am doing 99% of my programming in Core, but once we're finished with the X# runtime, I plan to write some such apps, too.

What I currently use very regularly and I am glad to have them as I didn't have them in VO, are things like method overloading, easy strong typing, interfaces, foreach (makes the code a lot cleaner and less error prone), enumerations (and enumerators), scoped locals. And of course many classes from the huge collection of classes available in the system libraries. Those are the everyday things, but of course there are a lot more to be used when needed. I am so used to all the new features that it has became very hard for me going back yo VO if I sometimes need to.

Chris

PS. Of course I am not saying everything is perfect in X# (yet ), just explaining why I like so much programming in it! Ah,forgot to mention also XIDE

[wriedmann]

Hi Dick,

you seem to like the role as "advocatus diaboli" <g>.

But let me explain a few things: the programming work in my small company (4 people) is about 20% maintenance and bug fixing of existing applications, 50% of adding new functionality to existing applications and the remainder of 30% are new applications, most for existing customers.

The percentages may vary, but nearly all of us have the need to write new applications, and new applications should be written in modern languages like X#.

As VO programmers we are used to have some extra functions that others had to write themselves. My own VO framework classes have many samples of code that was written by others, and enhanced and adapted by myself.
I have the same need in X#, and why not build a common stock of working and tested functions and classes - code that even it was written by community members, has the quaity and the support of the functions and classes of the core X# product,

It seems I'm not the only one that thinks that such a library would make X# programmers more productive, and why not, attract also new programmers to X#.

Wolfgang

P.S. I think I'm one of the few that has written a complete application in X# Core without any runtime, but I had to write a lot of functions that are now present in the runtime, and a lot of other classes that could help others to get started with native WinForms or WPF applications

[FFF]

I don't think I understand clearly what you propose. End users writing functions which the development team is going to add to X#?

Well, this is more or less the way, open source works
You may write your own helpers, as you did in VO, you may make this "visible" for others, you'll have to stand probably some critic for verbose/sloppy/wrong code from others, you may follow this, or stay with what you have. At that point you may pack this into dll. That's e.g. the status of "extensions" which provide to the vast ecosystem around Postgres...

If the consensus is, that your code is useful enough for a bigger group, it might be again reviewed and even possibly added to the runtime for the benefit of all.

Remember the days, when you know who promised, because you PAY you'll sit in the co-pilot's seat and influence the path the product follows? Unfortunately didn't hold... Now you only have to invest brain and time :cheer:

Karl

[ic2]

Hello Wolfgang, Chris, Karl,

you seem to like the role as "advocatus diaboli" <g>.

Not sure if I am. Of course I acknowledge that getting X# on the same level as C# feature-wise is good. I am also certainly not saying that the priorities should be different.

Only thing I know is that I would personally not be inclined to switch from VO to X# because of new functions and program features (as most of these IMO can be done just as well, nearly just as well or even better the 'old' way) but only when programming in X# works about as easy it does in VO with the least amount of problems to solve on converting it.

I just wonder if most VO users who wanted the latest programming technology have already long ago moved to C# (like Nick who wanted to use WCF) while those who feel most comfortable in VO have other priorities.

Apart from that Wolfgang: I think it's a good idea you propose. VO has become especially so useful because of the Fabtools, Ralph's error class and so on. If for X# this is all added in DLL's checked by the development team this would be great.

Dick

[wriedmann]

Hi Dick,

Only thing I know is that I would personally not be inclined to switch from VO to X# because of new functions and program features (as most of these IMO can be done just as well, nearly just as well or even better the 'old' way) but only when programming in X# works about as easy it does in VO with the least amount of problems to solve on converting it.

I don't think people will switch from VO to X# because of such added functionality.

Such functiionality should people help to get started or make them more productive in X#.

I know people that needs to switch to X# because their VO applications are so big that they become instable because of their size.
And I know people that need to make this switch because many functionality is not available to Win32 applications - my last sample is from today, where the Win32 functions don't return the correct user memberships from a Windows 2016 server - and the .NET functions do.

As I wrote several times, I have the pressure to switch from two sides: one are customers that are requesting new GUI enhancements possible only with WinForms or WPF, and the other are functionalities or SDK that are available only in .NET (for example access to various Google APIs like AdWords).

For sure, a tools library, maybe in the namespace xsharp.tools, would help a lot, and I'm expecting that people is requesting help and then the resulting functionality is added to the Tools lib.
And that will be a work in progress, and therefore it is important that is will be updated with the X# runtime.

Wolfgang

[ic2]

Hello Chris,

Foreach (makes the code a lot cleaner and less error prone),

You have a lot more knowledge in this area than I have but I am not sure why ForEach is less error prone. Personally I dislike Foreach a bit because I don't "see"/"control how the loop. I start with setting a variable (say nI) to determine the number of elements to loop through. Then I have a clear FOR..NEXT and I am able to inspect individual components (e.g. setting a breakpoint when nI = 10) and also to stop or even modify the loop variable.

In this article I found that unless you loop through a collection, FOR..NEXT is a lot faster too:

https://analystcave.com/vba-for-loop-vs-for-each-loop/

In my C# programs I mainly use FOR..EACH when I need to go through all files in a directory. But I think that the C#
foreach (var fi in di.GetFiles(cSearch)) is not really cleaner than an X# nFiles:=Directory.GetFiles;for ni:=1 upto nFiles ... NEXT.

Dick

[rjpajaron]

Hi Wolfgang,

Remember the VOLib of Richard Press? (no sure of the name). But I have that in my core lib, unmodified all this year: 20+ years. I am still calling it in many code unmodified. guess what? I ported two functions from it days ago and works great, no compile errors. Of course, it is in VO language mode.

Regards,

Rene