[c# .NET] .Focus() heeft niet beoogde effect

[reyan]

Ik heb een form met wat textboxjes en een aantal knoppen. Als je op bepaalde knoppen drukt dan worden bepaalde textboxen disabled. Afhankelijk van de invoer kan het zijn dat meteen hierna bepaalde invoervelden weer beschikbaar (enabled) worden. Voor de gebruiksvriendelijkheid had ik hierbij graag een bepaalde control de focus gegeven zodat de gebruiker meteen weer kan beginnen met invoeren.

Dat lijkt eenvoudig denk je:

code:

textBox.Enabled = true;
textBox.Focus()

Maar dat werkt dus niet... Als ik controleer met .CanFocus en .Focused zoals in onderstaand voorbeeld dan krijg ik een gek resultaat:

code:

textBox.Enabled = true;
MessageBox.Show(textBox.CanFocus.ToString());    // true
textBox.Focus();
MessageBox.Show(textBox.Focused.ToString());     // false ???

De eerste messagebox geeft zoals verwacht true, maar de tweede false! Dus de textbox *kan* de focus krijgen maar wanneer ik de focus geef dan weigert ie... Maar waarom? Wat doe ik mis? Misschien interpreteer ik het nut van .Focus() verkeerd, maar hoe kan ik anders mijn beoogde resultaat bekomen?

[Verwijderd]

Dit zou volgens mij moeten werken. Probeer van de textbox de event LostFocus eens af te vangen, zo kun je zien hij misschien de focus verliest aan een andere control.

Even googlen... Probeer het dus eens met Select()

[ Voor 28% gewijzigd door Verwijderd op 27-09-2005 09:37 ]

[phYzar]

http://msdn.microsoft.com...assactivecontroltopic.asp

Werkt dit misschien?

C#:

this.ActiveControl = textBox;

[pjvandesande]

Dat klinkt allemaal als workarounds, het zou gewoon moeten werken mits de textBox niet invisable is.

Bij mij werkt het iig wel. Heb je ergens nog Validate events die het misschien kunnen verpesten?

[Verwijderd]

Volgens mij moet het gewoon met .Select() werken, in de link die ik gaf had diegene hetzelfde probleem...

[reyan]

De oplossing van Boland werkt inderdaad wel. Bedankt alvast daarvoor. phYzar's oplossing doet even weinig als mijn stukje code...

Hoewel ik het nu wel werkende heb met Boland's idee vraag ik me toch af waarom het met .Focus() niet werkt. Dat is toch precies waar .Focus() voor dient of ben ik soms mis?

questa: De textbos is steeds visible en er is geen validate code die dit in de war zou kunnen schoppen.

[pjvandesande]

Verwijderd schreef op dinsdag 27 september 2005 @ 09:42:
Volgens mij moet het gewoon met .Select() werken, in de link die ik gaf had diegene hetzelfde probleem...

Select is iets anders dan focus, select activeerd alleen een control en Focus zet de input focus op een control.

Control.Select Method
Activates the control.

Met select kun je ook nog child controls activeren.

Control.Focus Method
Sets input focus to the control.

Hiermee set je echt de input focus op de control.

[pjvandesande]

reyan schreef op dinsdag 27 september 2005 @ 09:46:
De oplossing van Boland werkt inderdaad wel. Bedankt alvast daarvoor. phYzar's oplossing doet even weinig als mijn stukje code...

Hoewel ik het nu wel werkende heb met Boland's idee vraag ik me toch af waarom het met .Focus() niet werkt. Dat is toch precies waar .Focus() voor dient of ben ik soms mis?

questa: De textbos is steeds visible en er is geen validate code die dit in de war zou kunnen schoppen.

Dat is vreemd. Gebeurt het misschien in een anderen thread oid?

Als ik hier even een simple testje maak werkt het namelijk prima.

[Verwijderd]

questa schreef op dinsdag 27 september 2005 @ 09:47:
[...]


Select is iets anders dan focus, select activeerd alleen een control en Focus zet de input focus op een control.

Control.Select Method
Activates the control.

Met select kun je ook nog child controls activeren.

Control.Focus Method
Sets input focus to the control.

Hiermee set je echt de input focus op de control.

Ja, dat weet ik wel, ik snap ook niet waarom het niet werkt met Focus...

@Reyan: Graag gedaan Heb je de LostFocus-event al geprobeerd?

[pjvandesande]

C#:

using System;

namespace MaxProductiviteitsManager
{
    /// <summary>
    /// Summary description for Form1.
    /// </summary>
    public class Form1 : System.Windows.Forms.Form
    {
        private System.Windows.Forms.TextBox textBox1;
        private System.Windows.Forms.TextBox textBox2;
        private System.Windows.Forms.Button button1;

        public Form1()
        {
            InitializeComponent();
        }

        private void InitializeComponent()
        {
            // Initialize geneuzel
        }

        private void button1_Click(object sender, System.EventArgs e)
        {
            textBox2.Enabled = true;
            textBox1.Enabled = false;

            textBox2.Focus();
        }
    }
}

Werkt prima.

[ Voor 199% gewijzigd door pjvandesande op 27-09-2005 09:54 ]

[reyan]

Update: Boland's methode werkt dus niet altijd. Soms wel, soms niet... Vreemde boel hoor.

Ik ga even de LostFocus stuff coden.

[whoami]

Je zit, zoals questa al vraagt, niet met meerdere threads te werken ?

[Janoz]

Zou het misschien veroorzaakt kunnen worden doordat een object pas de focus kan krijgen wanneer het daadwerkelijk visable is? Misschien is setVisible wel een event dat pas wordt afgehandeld bij een (eventueel door dit event geschedulde) redraw. Het focus event wordt misschien wel ergens anders afgehandeld. Als deze dan eerder afgehandeld wordt dan het setVisible event lukt het dus niet.

Misschien werkt het wel wanneer er eerst een redraw of proccesEvents achtig iets tussen staat?

[pjvandesande]

Janoz schreef op dinsdag 27 september 2005 @ 09:57:
Zou het misschien veroorzaakt kunnen worden doordat een object pas de focus kan krijgen wanneer het daadwerkelijk visable is? Misschien is setVisible wel een event dat pas wordt afgehandeld bij een (eventueel door dit event geschedulde) redraw. Het focus event wordt misschien wel ergens anders afgehandeld. Als deze dan eerder afgehandeld wordt dan het setVisible event lukt het dus niet.

Misschien werkt het wel wanneer er eerst een redraw of proccesEvents achtig iets tussen staat?

Dit zou je kunnen testen met een Application.DoEvents, alleen als ik een simple testje run is er niets aan de hand.

Ik denk dat of een anderen control de focus opeist oid of valideting event schopt het in de war, alleen de TS geeft al aan dat dit niet het geval is of hij werkt buiten de STAthread.

[whoami]

Janoz schreef op dinsdag 27 september 2005 @ 09:57:
Zou het misschien veroorzaakt kunnen worden doordat een object pas de focus kan krijgen wanneer het daadwerkelijk visable is? Misschien is setVisible wel een event dat pas wordt afgehandeld bij een (eventueel door dit event geschedulde) redraw. Het focus event wordt misschien wel ergens anders afgehandeld. Als deze dan eerder afgehandeld wordt dan het setVisible event lukt het dus niet.

Dan zou de CanFocus imho toch ook false moeten opleveren.

[reyan]

De LostFocus brengt geen uitkomst... Als ik in de textbox typ en dan op een button klik dan zie ik dat de focus verhuist naar de button, maar op het moment dat textBox.Focus() uitgevoerd wordt is er geen LostFocus event... De focus blijft gewoon bij de button. Het lijkt wel alsof de Focus() gewoonweg niet uitgevoerd werd (maar het plaatsen van MessageBoxes toont wel duidelijk aan dat dat stuk code wel degelijk uitgevoerd wordt).
Als een andere control de focus zou opeisen dan zou toch nog op z'n minst de LostFocus event aangeroepen moeten worden, niet? Of zou een andere control de focus niet vrij willen geven? Dat kan dan haast enkel de button zelf zijn (die logischerwijs de focus heeft na erop te klikken). Maar dat is een doodgewone button die gewoon gegevens uit de textboxes (.Text) verzamelt en doorstuurt naar een server.

questa: in je eenvoudige voorbeeld werkt het voor mij ook. Maar niet in het programmaatje dat ik nu aan het schrijven ben. En het is niet dat het zoiets complex is... Het is voor zover ik weet geen multithreaded applicatie.

[whoami]

Wat is de waarde van de CausesValidtion property van de control die de focus heeft voordat je de 'Focus' method van die andere control oproept ?

Je hebt ook geen event-handlers die gekoppeld zijn aan de Validating event ?

[Verwijderd]

Post de relevante code eens dan... Dus het initaliseren en de onclick-methode.

[Janoz]

whoami schreef op dinsdag 27 september 2005 @ 10:00:
[...]

Dan zou de CanFocus imho toch ook false moeten opleveren.

Dat ligt eraan. Wordt de canFocus gebaseerd op de staat die in het geheugen staat of wat er daadwerkelijk al is afgebeeld. In principe ben ik het helemaal met je eens, maar in dit geval gaat er blijkbaar iets mis.

Sowieso is de api in de war aangezien het vlak daarna wel false oplevert.

[reyan]

Wacht even... Ik heb mezelf vergist . Het is ondertussen wel een multithreading applicatie geworden. Ik heb de netcode daarstraks non-blocking gemaakt met asynchrone callbacks. Dan krijg je eigenlijk een multithreaded applicatie, nietwaar?

Maar dit is zowat mijn eerste contact met zulke applicaties. De CanFocus doet toch uitschijnen dat het focus geven moet lukken? In welk aspect kan een andere thread dan beletten dat dit gebeurt?

[whoami]

Janoz schreef op dinsdag 27 september 2005 @ 10:26:
[...]


Dat ligt eraan. Wordt de canFocus gebaseerd op de staat die in het geheugen staat of wat er daadwerkelijk al is afgebeeld. In principe ben ik het helemaal met je eens, maar in dit geval gaat er blijkbaar iets mis.

Sowieso is de api in de war aangezien het vlak daarna wel false oplevert.

De enige reden waarom het vlak daarna false oplevert (de property die zegt of het control nu al of niet de focus heeft), is, IMHO, dat de control die focus 'verliest', een validating event - handler heeft, die opgeroepen wordt, en waar de Cancel property van het CancelEventArgs object in die event-handler op true gezet wordt. Dit is nl. wat de help hierover zegt:

Focus events occur in the following order:

Enter
GotFocus
Leave
Validating
Validated
LostFocus


If the Cancel property of the CancelEventArgs object is set to true in the Validating event delegate, all events that would normally occur after the Validating event are suppressed.

Ik zie niet direct een andere reden....

[whoami]

reyan schreef op dinsdag 27 september 2005 @ 10:30:
Wacht even... Ik heb mezelf vergist . Het is ondertussen wel een multithreading applicatie geworden. Ik heb de netcode daarstraks non-blocking gemaakt met asynchrone callbacks. Dan krijg je eigenlijk een multithreaded applicatie, nietwaar?

Maar dit is zowat mijn eerste contact met zulke applicaties. De CanFocus doet toch uitschijnen dat het focus geven moet lukken? In welk aspect kan een andere thread dan beletten dat dit gebeurt?

Bij multithreaded applicaties, moet je er altijd voor zorgen dat, als je iets wijzigt aan een windows - control, je dat altijd doet op de thread die ook de control 'gemaakt' heeft, in dit geval op de UI thread dus.

[riezebosch]

Of multithreading het probleem is kan je vrij eenvoudig testen door this.InvokeRequired te checken.

[ Voor 3% gewijzigd door riezebosch op 27-09-2005 10:33 ]

[reyan]

whoami schreef op dinsdag 27 september 2005 @ 10:32:
Bij multithreaded applicaties, moet je er altijd voor zorgen dat, als je iets wijzigt aan een windows - control, je dat altijd doet op de thread die ook de control 'gemaakt' heeft, in dit geval op de UI thread dus.

Mjah, maar als ik in de callback hetvolgende zet:

code:

textBox.Enabled = true;
textBox.Text = "Blah blah";
textBox.Focus();

Dan verandert de tekst van de textbox wel, maar niet de focus. En *stel* dat ik dit dan zou willen doen in de UI thread, hoe kan ik dan vanuit de callback opdracht geven naar de andere thread?

Update... Ben MSDN al aan het lezen over invokes enzo

[ Voor 7% gewijzigd door reyan op 27-09-2005 10:43 ]

[Janoz]

whoami schreef op dinsdag 27 september 2005 @ 10:30:
[...]


De enige reden waarom het vlak daarna false oplevert (de property die zegt of het control nu al of niet de focus heeft

Interpretatie foutje van mijn kant. Ik dacht dat er 2x werd opgevraagd of het element de focus kon krijgen, maar het zijn twee verschillende properties zie ik nu.

[reyan]

riezebosch schreef op dinsdag 27 september 2005 @ 10:33:
Of multithreading het probleem is kan je vrij eenvoudig testen door this.InvokeRequired te checken.

Dat geeft inderdaad true in de callback... Dus het probleem zit 'em wel degelijk in de multithreading die onstaan is door m'n programma's netcode non-blocking te maken.

MSDN maar weer eens doorspitten

[Janoz]

Sowieso is het ook wat netter om deze functionaliteit daadwerkelijk in je UIThread te implementeren. Maak er desnoods een apparte methode van. Deze zou je dan op 1 of andere event basis aanroepen

[pjvandesande]

C#:

private void EnableMyTextBoxAndFocusIt()
{
     textBox.Enabled = true;
     textBox.Text = "Blah blah";
     textBox.Focus();
}

En dan in je code die gerunt word in een anderen Thread:

C#:

MethodInvoker invoker = new MethodInvoker( EnableMyTextBoxAndFocusIt );
Invoke( invoker );

[reyan]

Ik had ondertussen al een voorbeeld in de MSDN gevonden, maar toch nog bedankt voor je voorbeeld questa! Het zootje werkt nu naar behoren

Bedankt iedereen die meegeholpen heeft in deze thread!

[pjvandesande]

reyan schreef op dinsdag 27 september 2005 @ 11:04:
Ik had ondertussen al een voorbeeld in de MSDN gevonden, maar toch nog bedankt voor je voorbeeld questa! Het zootje werkt nu naar behoren

Bedankt iedereen die meegeholpen heeft in deze thread!

Hoe heb je het nou precies op gelost, ben ik wel heel erg benieuwd naar eigelijk.

[riezebosch]

questa schreef op dinsdag 27 september 2005 @ 10:45:

C#:

private void EnableMyTextBoxAndFocusIt()
{
     textBox.Enabled = true;
     textBox.Text = "Blah blah";
     textBox.Focus();
}

En dan in je code die gerunt word in een anderen Thread:

C#:

MethodInvoker invoker = new MethodInvoker( EnableMyTextBoxAndFocusIt );
Invoke( invoker );

Dit kan natuurlijk ook gewoon (in een functie) in je GUI zelf. Persoonlijk vind ik dat mooier, omdat de aanroepende (multithreaded) class geen weet hoeft te hebben wát er nou eigenlijk gedaan wordt met de functie.

Om jouw voorbeeld daarnaar om te buigen:

C#:

private void EnableMyTextBoxAndFocusIt()
{
     if (this.InvokeRequired)
     {
          this.BeginInvoke(new MethodInvoker(EnableMyTestBoxAndFocusIt));
     }
     else
     {
          textBox.Enabled = true;
          textBox.Text = "Blah blah";
          textBox.Focus();
     }
}

Theoretisch gezien is dit misschien niet zo mooi, omdat hij in een oneindige (recursieve) loop zou blijven hangen wanneer de invoke niet lukt, maar volgens mij mag je er met een BeginInvoke wel vanuit gaan dat de volgende keer InvokeRequired niet nodig is

Je zou het natuurlijk ook op kunnen splitsen naar twee functies. Eentje die vanuit de andere thread aangeroepen wordt en controleert of een invoke nodig is. En een andere functie die daadwerkelijk de actie uitvoerd (al dan niet invoked).

[pjvandesande]

riezebosch schreef op dinsdag 27 september 2005 @ 11:43:
[...]

Om jouw voorbeeld daarnaar om te buigen:

C#:

private void EnableMyTextBoxAndFocusIt()
{
     if (this.InvokeRequired)
     {
          this.BeginInvoke(new MethodInvoker(EnableMyTestBoxAndFocusIt));
     }
     else
     {
          textBox.Enabled = true;
          textBox.Text = "Blah blah";
          textBox.Focus();
     }
}

Komt bij mij idd heel eng over.

riezebosch schreef op dinsdag 27 september 2005 @ 11:43:
[...]


Dit kan natuurlijk ook gewoon (in een functie) in je GUI zelf. Persoonlijk vind ik dat mooier, omdat de aanroepende (multithreaded) class geen weet hoeft te hebben wát er nou eigenlijk gedaan wordt met de functie.

Ik los dit meestal op met:

C#:

private void EnableMyTextBoxAndFocusIt()
{
     if (this.InvokeRequired)
     {
          this.BeginInvoke(new MethodInvoker(DoEnableMyTextBoxAndFocusIt));
     }
     else
     {
          DoEnableMyTextBoxAndFocusIt();
     }
}

private void DoEnableMyTextBoxAndFocusIt()
{
      textBox.Enabled = true;
      textBox.Text = "Blah blah";
      textBox.Focus();
}

[riezebosch]

questa schreef op dinsdag 27 september 2005 @ 11:49:
[...]

Ik los dit meestal op met:

C#:

private void EnableMyTextBoxAndFocusIt()
{
     if (this.InvokeRequired)
     {
          this.BeginInvoke(new MethodInvoker(DoEnableMyTextBoxAndFocusIt));
     }
     else
     {
          DoEnableMyTextBoxAndFocusIt();
     }
}

private void DoEnableMyTextBoxAndFocusIt()
{
      textBox.Enabled = true;
      textBox.Text = "Blah blah";
      textBox.Focus();
}

Zo bedoelde ik de 2e uitleg dus ook. Zou alleen wel EnableMyTextBoxAndFocusIt public maken

[Verwijderd]

Het werken met UI's en threads is idd vervelend. Wat ook een probleem zou kunnen zijn is in de constructor dit soort dingen te doen. Dan heeft het Form nog geen handle en dat kan hij dat niet. Misschien heb je hier iets aan?

[pjvandesande]

riezebosch schreef op dinsdag 27 september 2005 @ 12:17:
[...]


Zo bedoelde ik de 2e uitleg dus ook. Zou alleen wel EnableMyTextBoxAndFocusIt public maken

Doe dan protected, public is niet nodig lijkt mij. Alleen classes die afgeleid zijn van deze class kunnen misschien baar hebben bij EnableMyTextBoxAndFocusIt, hoewel ik dit dan weer in een propertie zou gooien.

Dus als je bijvoorbeeld de Age op 12 zet, disabled hij automatisch het de I Want Porn checkbox.
Maargoed, hangt net af van waarom je een iets enabled en focused.

[H!GHGuY]

riezebosch schreef op dinsdag 27 september 2005 @ 11:43:

C#:

private void EnableMyTextBoxAndFocusIt()
{
     if (this.InvokeRequired)
     {
          this.BeginInvoke(new MethodInvoker(EnableMyTestBoxAndFocusIt));
     }
     else
     {
          textBox.Enabled = true;
          textBox.Text = "Blah blah";
          textBox.Focus();
     }
}

Dit is idd de nette manier, ware het niet dat je hier BeginInvoke asynchroon aanroept. Meestal is dit voor UI operaties niet nodig, maar het zou netter zijn moest je ook de EndInvoke laten aanroepen op een bepaald moment. Beter nog is om rechtstreeks this.Invoke aan te roepen. dan weet je ook zeker dat wat je wil (synchroon) is uitgevoerd wanneer je uit je functie komt. Nu kan het zijn dat je functie terugkeert en dat textBox nog geen focus heeft!

Wat het werken met Invoke en InvokeRequired betreft:
Invoke post eigenlijk een message in de message queue van de window (of het desbetreffend object) en wacht vervolgens tot de UI thread deze volledig verwerkt heeft om dan te returnen. Je moet dus geen schrik hebben van de

C#:

if (InvokeRequired) // return System.Threading.Thread.CurrentThread != myUIThread
  // Invoke(...)        // post message in queue van UI Thread
else
{
  // code hier
}

constructie. Deze doet hetzelfde als ware het

C#:

//code hier

maar is threadsafe