[C#] Treeview afterlabeledit bug

Pagina: 1
Acties:

  • DrDelete
  • Registratie: Oktober 2000
  • Laatst online: 21:14
Als ik een node toevoeg aan een treeview met default de naam "NewNode", deze selected maak (.selectedNode op de treeview), zet ik 'm daarna in editmode (.beginedit op de node). Na het geven van een ENTER zonder verder iets te wijzigen wordt het afterlablevent afgevuurd.

In het afterlabelevent ontvangt ik dan e.Label null, dit had ik niet verwacht, is dit een bug?

(C#, .NET 1.1, VS2003 SP1)

[ Voor 3% gewijzigd door DrDelete op 16-06-2008 09:31 ]


  • Niemand_Anders
  • Registratie: Juli 2006
  • Laatst online: 09-07-2024

Niemand_Anders

Dat was ik niet..

Ja, dat is normaal en geen bug. Als je namelijk in de MSDN had gekeken kan had je namelijk kunnen zien aan het voorbeeld dat er eerst op 'null' wordt gecontroleerd en daarna of de lengte groter dan 0.

In dat geval kun je namelijk e.CancelEdit op 'true' zetten (of e.Node.EndEdit(false) aanroepen) en dan wordt de oorspronkelijk tekst van je label hersteld.

Maar ik denk dat het verstandig is dat je eens in de MSDN de voorbeeld code van TreeView.AfterLabelEdit moet bekijken.

If it isn't broken, fix it until it is..


  • DrDelete
  • Registratie: Oktober 2000
  • Laatst online: 21:14
Niemand_Anders schreef op maandag 16 juni 2008 @ 09:31:
Ja, dat is normaal en geen bug. Als je namelijk in de MSDN had gekeken kan had je namelijk kunnen zien aan het voorbeeld dat er eerst op 'null' wordt gecontroleerd en daarna of de lengte groter dan 0.

In dat geval kun je namelijk e.CancelEdit op 'true' zetten (of e.Node.EndEdit(false) aanroepen) en dan wordt de oorspronkelijk tekst van je label hersteld.

Maar ik denk dat het verstandig is dat je eens in de MSDN de voorbeeld code van TreeView.AfterLabelEdit moet bekijken.
wat zegt de e.label == null dan volgens jou? Ik had al lang natuurlijk naar de code uit MSDN gekeken en voor een groot gedeelte overgenomen maar ik snap niet waarom de e.Label null is. Het MSDN voorbeeld komt heel raar over:

code:
1
2
3
4
5
6
7
.....afterlabelevent(object sender, NodelLabelEditEventArgs e)
{
   if (e.Label != null)
   {
      //doe iets
   }
}


ik had verwacht dat de e.Label de nieuwe, actuele waarde zou bevatten

ik krijg de e.Label dus niet op != null

ps: het is wel een bijzonder geval, ik voeg een node toe vanuit programmacode en geef 'm een naam en zet 'm in edit mode. Wat de e.Label feitelijk zegt is: heeft de gebruiker de node-label veranderd? Dat is bij mij dus niet het geval, vanuit de edit-mode geef ik direct een enter. Feitelijk heb ik geen wijziging uitgevoerd, waardoor de e.Label null is. Zodra ik ook maar iets wijzig op de node-label is de e.Label wel != null. In de MSDN staat dit niet duidelijk uitgelegd.

[ Voor 20% gewijzigd door DrDelete op 16-06-2008 09:48 ]


  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Best logisch: je krijgt een Nodelabelediteventargs terug en er is geen edit geweest (en dus null). ;) En dat is prima gedocumenteerd.
The value of this property is null reference (Nothing in Visual Basic) if the user presses ESC to cancel the edit or presses ENTER without modifying the label text. If the user edits the label text, the value of this property is the new label text. This is true even if the final value of edited label text is the same as its original value.

[ Voor 61% gewijzigd door RobIII op 16-06-2008 10:30 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


  • DrDelete
  • Registratie: Oktober 2000
  • Laatst online: 21:14
RobIII schreef op maandag 16 juni 2008 @ 10:28:
[...]

Best logisch: je krijgt een Nodelabelediteventargs terug en er is geen edit geweest (en dus null). ;) En dat is prima gedocumenteerd.

[...]
oeps, ik heb een iets verouderde MSDN geinstalleerd staan, waar deze remarks section niet bij stond, juist deze info is zeer relevant in mijn context! Bedankt voor de link!