VFP Refresh() VS C# Refresh()

[Nro]

I have a very good experience in VFP 9 and a I’m a beginner in C#. I have a simple questions and I can’t find a good answer to .NET forums. I’m in the process of writing a simple app in C#.
In VFP, I can sub-class controls (ex. Label) and put code in the refresh() event

ex. :

DODEFAULT()
IF THISFORM.lnLg = "FR" THEN
 this.Caption = "Mon nom est Mario"
ELSE
 this.Caption = "My name is Mario"
ENDIF

I put this label in a form, and issue a Refresh() of the form. As expected all the Refresh() events of all the controls on the forms are issued.

I know that it’s not the good forum for this questions, but I think you know the behaviour in VFP, and don’t know how to explain this to C# specialist.

Thanks for your help.
Nro

 

[Olaf Doschke]

Your real question is not about refresh, but about internationalisation or cultures.

Here's a primer on that:
[URL unfurl="true"]https://msdn.microsoft.com/en-us/goglobal/bb688115.aspx[/url]

Besides, it depends on the UI used (winforms vs wpf vs html) what events exist, that will redraw the ui and enable you to hook in. In winforms controls you have the paint event. There is nothing like that in WPF, the concept differs very much on what and how dirty regions are redrawn.

Bye, Olaf.

 

[Olaf Doschke]

Oh, and by the way: Refreshes happen more often than you think and it's not a good idea to put internationalisation into that event even in VFP. You can use Init of course and define your own cascading trigger by a property you add with an assign method. Then SetAll and you have your caption translation event separate from any other refresh. Same applies to anything you are not only an event sink, but the event initializer, like you are, if a user switches languages via menu or button.

Bye, Olaf.

 

[Mike Lewis]

Nro,

In your scenario, the time to change the label is not in the Refresh, but when the form is instantiated. As Olaf pointed out, that means you do it in the Init (or equivalent). Also, if the user is able to change the language setting at run time, you should update the label at the point that he makes that change. Doing it in the Refresh is completely unnecessary.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Nro]

Thanks for your quick answers.

I think the example I gave you is not very significant of what I want to do. I’m aware of the localization ability of .Net I know that the caption of a label is always better to be done in the init (constructor) or the class. A better example could be to enable or not a text box based on the form status (read only or not)

In VFP, as in .Net, all the base controls (text box, labels, button…) are sub-classed. In VFP, at runtime, when I issue a THISFORM.Refresh() (or any control Refresh()), all the Refresh() event or of all the child controls are triggered.

It’s that behaviour I want to achieve in C#. Maybe it’s not possible and I’ll have to program a routine to manually call some Refresh() method for each controls (like I did in foxpro 2.6)

I can’t use the .Net paint event because of the performance impact. There is the .Net Invalidate event, but it’s not really what I want.

Maybe I’ll give the .Net forum a chance

Olaf, I’m working with Windows Forms.

Thanks again for your input.

Nro

 

[Olaf Doschke]

In .NET you have far better chances to react to events with a handler, so you should be able to bind something in your .NET form to a status change like change from read to edit mode or reacting to a changed current user (logout&login of application users within the application session, if your applications users differ from windows accounts, for example).

That's nothing I'd expect to be done with some standard events.

Bye, Olaf.

 

[clipper01]

Hi Nro ,
like any who move from VFP to .Net , you still keep 'thinking' VFP for quite a while. For example, you assume that there is some equivalent to e.g. the Init and Refresh methods in VFP that conveniently bubble down from the parent form to the controls. You also assume that normal 'best practise ' is to start off by sub-classing main controls as you would in VFP . I did this to start with when converting some VFP apps, see code snippet below. Basically it adds 2 methods DoInit and DoChange to the Combo Box. It also changes ( trivially ) the standard readonly back-color of a textbox.

using System;
using System.Windows.Forms;

using System.Text;
using System.Drawing;
using System.Drawing;

namespace UserLib
{
    public delegate void EventHandler();
   public partial class uComboBox : ComboBox
    {
        public event EventHandler DoInit;
        public event EventHandler DoChange;
        public uComboBox()
        {
            this.MaxDropDownItems = 30;
            this.DropDownStyle = System.Windows.Forms.ComboBoxStyle.DropDown;
        }
    }

   public partial class uTextBox : TextBox
    {
        public uTextBox()
        {
            this.BackColor = System.Drawing.Color.FromArgb(255, 255, 220);
        }
    }

}

You then build your class UserLib , include it in your Winform References and use e.g. uComboBox instead of the standard CombBox ... all very VFP-like. The 2 new methods DoInit and DoChange appear in Intellisense but it does not really help to fire these events. You could define a static event , have these methods subscribe to it and then sort of automate the way VFP forms work. BUT .... after going down this route for a few apps, I realised it was just 'fighting' the .net way of doing things your code gets complicated etc etc . So just the simple solution is better, write a method to do set various properties and just call it when you need to ( see the example you started off with )

private void SetTexts()
        {
txtBox1.text= (lnlg=="Fr") ? "Mon nom est Mario" :"My name is Mario" ;

// more settings
	}

So... the best advice is , forget the way VFP does things ( just like you had to forget the way Fox2.6 did when you moved to Visual Foxpro) , take one simple app and rebuild it from scratch and get familiar with the .net way

 

[Nro]

Thanks Olaf.

You are perfectly right about stop thinking VFP. But I it’s like old slippers. I’m studying .Net for a while now and I’m not afraid of this challenge. It took me a lot of time to get used of OOP in VFP and there is a lot of similarities between VFP and .Net

Thanks again

Nro

 

[Olaf Doschke]

Kudos should go to clipper more than to me in regard to the thought "stop thinking VFP".

I merely pointed to .NET's superior event handling capabilities, but clipper is right. In this case you don't want to react to an event, you want to actively change something. You only use the refresh in VFP, as it's the only easy way to let all controls react, but in .NET you can let each control react by letting them subscribe to an event publisher. And clipper even says instead of triggering all controls to react to a mode change, simply call into them.

Bye, Olaf.

 

[Nro]

Huh... clipper ?

 

[clipper01]

Sean M , that's me , long time ago used clipper , hence nickname

 

[Nro]

I’m sorry Sean. I think I need some coffee.
Thanks again
Nro

 

[Mike Lewis]

long time ago used clipper , hence nickname

Good way of choosing a nickname.

Best wishes,

COBOL



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Dan Freeman]

Good way of choosing a nickname.

I agree.

Alto Clarinet

 

[montypython1]

I too agree.

Dave "Stone Tablet" Higgins

 

[Nro]

Very good article of Code Magazine for moving from VFP to .Net, by Kevin S Goff

http://www.codemag.com/Article/0703092

And thanks for your input Olaf, clipper, COBOL , Alto Clarinet and Stone tablet

RPG2