xsharp.eu

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