TOPIC:

Hello All

I don't want to comment on the coding side of things since there are others far better qualified than me to do so.

However, largely because of comments in other forums, I felt it may be worth flagging up some things to bear in mind when programming a .Net Application.

Just one really: .Net brings computational electronics close to what we do in real life. But miss-understandings can occur.

The fact is in real life we can go somewhere and do something.

OR

we can go somewhere and do nothing.

These two options can lead us to think there is only one thing we can do.

But in fact both these options are equally valid and one is dependent on the other. So any thinking or action must always take into account Two interdependent alternatives not One.

This makes it difficult, if not impossible, to answer any question that asks for a Yes/No type answer.

The fact is that the electronics enables us to go somewhere (in computer memory) and do something.

OR

go somewhere (in computer memory) and rather than do nothing as in the real world, simply wait.

Wait - in the real world for someone else to do something for us - in the electronic world wait for another thread to do something on behalf of our program.

If our program does not have a thread to do something for us we would wait for ever, or lock up - hence the Ctrl-Alt-delete option on our pcs.

So it's all to do with threads, and the Garbage Collector concentrates all thread manipulation in respect of .Net memory control in one place. (Note .Net Memory is a subset of total memory).

Knowledge of the workings of the GC is not necessary, but it means programmers can think of their programs in the same way as how they would do things in real life and then commit to code.

Hope that makes some sense.

Terry

Thank you, Wolfgang. Works! I think we're moving in the right direction.
"Resolution independent" is the term, I believe. The app should render properly no matter the resolution of the client screen.
People with high-resolution displays (and there are more and more every day) will be happy with this.
Obviously there's much still to learn but you got me started. Thank you very much.

Hi Joe,
if you asked me a year ago if WPF or Windows Forms where the correct way to go I had answered "for sure WPF" because of its many advantages.
But now I'm not so sure if there is not something new coming around the corner.
If I try to give a development time for the different GUI types I work on, I have to say something like this:
VO or VO GUI classes in X#: 1x (the reference)
Windows Forms: 3x (3 times the time I need for VO GUI)
WPF: 5x (5 times the time I need for VO GUI).
I'm trying to cuto down the times but it is not that easy, and I hope to have the VO GUI compatible Windows Forms classes ready sometimes, so I can go with Windows Forms at the development times of VO GUI.
Wolfgang

Wolfgang, I try to listen and learn because I'm trying to solve problems you've already worked out.
I'm sure everyone on this forum is looking forward to your GUI classes.
But if it doesn't solve the high-resolution problem, then I'm going to try to slog ahead with WPF. This is a pocketbook issue for me and presumably others whose client base includes non-windows users and home users of high-resolution devices.
Can you foresee another way out of this problem other than WPF ? If not then I will soldier on and let everyone know what I've learned.
Thanks to the input of you, Terry, Dick, Fabrice, Joachim and others on this forum, I was able to choose what I think will be the correct path out of the DBF forest. So now, as you see, I'm trying to choose a GUI direction.

Hi Joe
I can understand why you are trying to tie in WPF with high resolution devices. But that is not IMO the real link.
WPF (coding), yes, will take some time to learn. But the principle is simple enough. It is simply a way of controlling on-screen layout at the time your program is run. Effectively, it takes a quick look into the future just before some screen layout is rendered, and by calculating layout co-ordinates before rendering. But I guess you know this anyway.
WPF is well worth learning IMO. Even if something better is in the pipeline, the principles will remain the same. A brief mental excursion FWIW into Windows 11 tells me this will be the case in this up-and-coming environment.
The code for WPF is not part of the Windows O/S, being distributed independently in the GAC.
Now, the link to high resolution devices: this comes about from the “structural infrastructure of .Net itself”.
.Net isolates your program code from its hardware host in a way that is just not possible with a non-netted language compiler. This means that your program will run, carry out the same geometric calculations (all ratios in respect of screen layout) and therefore adjust to whatever hardware your users have.
You ask: “Can you foresee another way out of this problem other than WPF?” My answer to that is yes, many ways, but they would all have to adhere to the same principles as WPF which has done it all for you - reliably.
Terry

Hi Joe,
please don't let you shock by the development times I have given: WPF makes so many things better than Windows Forms and the VO GUI, but you have to rethink all your windows because WPF applications are more like web applications than Windows applications.
And at least our own web development is ways slower than development in WPF because we don't use any complex frameworks as also our web applications have to work for 10 years or longer (or better: some of our web applications are more than 10 years old and working very well until today).
Wolfgang

Here's a related question, the answer to which will partially solve the tiny-type complaints:

How does one change the default font size in VO?

How does one change the default font size in XIDE ?

Right now everything on the Window editor defaults to 8-point. I'd like to globally change that to 10 and maybe 12.

Hi Joe,
AFAIK that is not possible, not in VO and not in XIDE.
What I have done: I'm using only my subclassed control classes, and there I can change the font globally whenever I like.
Wolfgang

Thank you, Wolfgang. If you haven't been able to figure it out then that's probably the answer: the only solution is to subclass.

Hi Joe,
I'm far from knowing all the undocumented settings in the VO IDE - the only person you can give the correct answer is Robert (for VO), and Chris (for XIDE).
If that is is important, maybe you can ask Chris if he can implement that in XIDE.
Wolfgang

I'm trying to move into WPF so unless others think it's an important upgrade, I would not ask Chris to elevate it on his to-do list. For me enlarging the font is merely a temporary stopgap to relieve some of the tiny-text problems while I figure out the new GUI.

Are you guys talking about the font size in the editor in the IDEs themselves? That's very easy, there's an option in the preference window in both VO and XIDE. Also CTRL + Mouse Wheel works on the fly while in the editor in both IDEs. But I guess I have probably misunderstood you!

Hi Chris,
it is about the default font that the Window Editor uses for the different controls, and AFAIK there is no setting for this.
For the source code editor and the explorers is settable (and in fact I have set my editors font to the Hack font).
Wolfgang

Hi Wolfgang and Joe,

Ah, thanks, I understand now. Actually there is a way in XIDE to do this (or sort of). If you unzip and copy this file to the project \Config\ folder:



then every time you add a new TextBox control to a winform, it will automatically set the Font property to Courier New, with a font size of 20. This is done through those lines in the file:


In the same way, it is possible to set the default font for every control that you need to, for example you can add those lines to set the default font also for CheckBoxes:


But this will affect only new controls you put to forms, old controls will not change at all, you will need to set their property manually in the form editor. So I am not sure if this suitable for what you want to achieve, but it's worth a try..


Edit: Oh, I should also mention that this is working for the WinForms editor only, but if it's needed for the VOWED, I can enable it there, too..

Hi Chris,
thank you very much!
Is there any way to add that also to the VO compatible WIndow Editor?
Wolfgang

Hi Wolfgang,

Oh, I totally forgot, but I have already implemented this also for the VOWED, and even from the VOMED and VO Dbserver editor etc! You need to add a section [VOWINDOW] for the WED:


This will make all new SLEs have the mentioned caption and tooltip. But I see that for some reason this does not work for the font property, will look into it...

Edit: Font also works, it's just that the syntax is different (follows the way it is stored in the VO binaries):

Hi Chris,
this is great, thank you very much!
Wolfgang

Wolfgang, I tested this code on a high-resolution monitor, hoping it would resolve the "tiny type" problem. In other words: render everything as a percentage of screen size.
Is this the starting point? Is there a setting I'm missing? Should I attach an XAML ? Is there something I should read first ?
My two main goals are
1) move from DBF to SQL. That project is moving along.
2) Get into WPF so the apps will render properly on screens of all resolutions. Just getting started.
Can you point me in the right direction? Thank you

Wolfgang, BTW I was referring to the WPFDBF example that was posted.

Hi Joe

I have not looked at this thread for some time, but you asked for advice on future course of action with two objectives: WPF and DBF/SQL.

They are different avenues, both valuable so it is not really a choice. You will gain valuable insights across the board with either. Tackle them both independently.

So let's look at what you are doing: With the DBF/SQL route you are basically looking at a different syntax meaningful to SQL rather than DBF, and as SQL is standard across the board and likely to be with us for a few years hence, from a "get marketable" point of view it is both a valuable and viable route.

WPF is different: as you say it does enable proper rendering on screens of all resolutions. But IMO that is a technology aside. Following that route will give you other insights - valuable across the board.

With WPF you are basically "looking in to the future" like taking a sneak look at the final chapters of a thriller to find out who dun'it. Effectively this equates to late binding. Thus we take a look at screen size (or render size available on screen) then scale what we want to render accordingly - or perhaps give ourselves more rendering space such as using a scroll viewer.

All this is done in the blink of an eye and takes place between key-presses with plenty of time left over. You will surely re-enforce your own knowledge applicable across the board in all areas of software development.

I hope this makes some sense and helps a bit.

Terry