Rechtsklick abschießen

[TStringlist]

Zitat von DGL-luke:

aber wieso speichert man eigentlich immer die alte wndproc? wenn man sie eh nimmer braucht? nimmt doch nur speicherplatz weg

Also normalerweise wird die bisherige WndProc auch weiterhin benötigt. Wenn ich eine eigene WndProc schreibe, dann stelle ich die der bisherigen nämlich quasi nur voran. In meiner selbst geschriebenen WndProc kann ich die Messages dann manipulieren oder sonst irgendwie (zusätzlich) darauf reagieren, aber auf die große Masse der Messages werde ich dort nicht eingehen, was heißt: Die meisten Messages reiche ich normalerweise also trotzdem einfach immer nur an die bisherige WndProc durch, um dort dann auch weiterhin normal darauf zu reagieren, wie in deinem Fall ja auch. (Ergo muss diese bisherige WndProc also auch weiterhin gepointet bleiben, und zwar mit einer weiteren Variablen (vom Typ TWndMethod). Normalerweise kann man die dann nennen wie man will. Bei mir jedenfalls beginnen die immer mit so einem kleinen "old" als Namenspräfix..., ...und von daher dann wahrscheinlich auch dein kleines Missverständnis *g*)

[DGL-luke]

jo, is klar. dachte das inherited; is sowas wie inline;, haut also nur den code der davor steht rein.

EDIT: das mit dem onchanging is wohl besser.
@marabu: nein, ich bin nicht auf dem holzweg. habe das ganze mit einem leeren projekt und einer TListView ausprobiert.

EDIT2: @Lannes: wann wird $80 <> 0 true?????

EDIT3: selber drffugekommen...das magic word heisst operatorenrangfolge.

[Lannes]

Hallo,If (GetKeyState(VK_RButton) And $80 <> 0) Then wird True, wenn die rechte Maustaste gedrückt ist.
Der Status ist im höchsten Bit gespeichert, darum das "And $80 <> 0"

Man könnte genausogut folgenden Code nehmen:If HiWord(GetKeyState(VK_RButton)) <> 0 Then

[DGL-luke]

willst dus noch ein bisschen effizienter haben?

If (GetAsyncKeyState(VK_RButton) < 0) Then man beachte das ASync. und das <0.

ps: habs jetzt übrigens geschafft:

Delphi-Quellcode:

procedure TForm1.AusderListelschen1Click(Sender: TObject);
begin
while (LVList.Selected <> nil) do
 LVList.Selected.Delete;
end;

[TStringlist]

hmmm? Also wenn ich z.B. jetzt mal 10 Zeilen in der ListView selectiere und dann die Maus hinter einer dieser selectierten Zeile platziere, dann bekomme ich in ListView1Changing bei einem Drücken der rechten Maustaste keine Bestätigung mehr dafür, dass eben diese rechte Maus-Button jetzt auch tatsächlich gedrückt ist. Überall woanders schon, aber an einer solchen Stelle nicht. Irre ich mich da etwa?

Delphi-Quellcode:

procedure TForm1.ListView1Changing(Sender: TObject; Item: TListItem;
  Change: TItemChange; var AllowChange: Boolean);
begin  // dieses funktioniert leider nicht
  If (GetKeyState(VK_RButton) And $80 <> 0) Then beep; <- hier gibt's dann KEIN Beep
end;

edit: Ich meinte nur, weil das nämlich zufälligerweise auch gleichzeitig noch der ListView-Bereich ist, über dem sich bei einem Rechts-Klick dann auch die Selection der Zeilen ausschaltet.

[Lannes]

Hallo,

Zitat von TStringlist:

...Überall woanders schon, aber an einer solchen Stelle nicht. Irre ich mich da etwa?
...zufälligerweise...

Nein, und ja

OnChanging wird nur vor der Selectionsänderung aufgerufen.
Eine Selection wird geändert indem ein anderes oder zusätzliches(Multiselect) Item(Caption) angeklickt wird.
OnChanging wird nicht ausgelöst wenn eine Selection aufgehoben wird.

Fazit :
Nur bei Mausklick auf eine Caption eines Items wird OnChanging ausgelöst und darum kein "Beep"

[marabu]

Es ist durchaus beeindruckend, wie zäh ihr alle am selbst gestellten Problem dranbleibt und zum Schluss auch eine Lösung hinkriegt. Vom Standpunkt eines Profis aus gesehen ist es aber grober Unfug den Rechtsklick auf eine ListView abzuschalten.

In einem objekt-orientierten GUI gehört zu einer ListView (und nicht nur zu der) ein Kontextmenü, das über einen Rechtsklick zu aktivieren ist. Dabei ist es völlig erwartungskonform, dass die Selektion aufgehoben wird, wenn man nicht auf ein Item, sondern auf die Listview selbst (rechts-)klickt. Im Kontextmenü sind immer nur die Befehle zu sehen, die sich auf das Objekt beziehen. In betrachteten Fall ist das GUI-Objekt dann nicht der Inhalt (ListItems), sondern die ListView selbst. Im Kontextmenü stehen dann Befehle, wie z.B. "Einstellen des Hintergrundes" dieser ListView.

@DGL-Luke: Verstehst du jetzt, was ich mit Holzweg meinte? Hätte ich das hier in meinem ersten posting geschrieben, dann hätte ich diesen thread eventuell abgewürgt - das wollte ich nicht.

Grüße vom marabu

[TStringlist]

na ja, so ganz unrealistisch war DGL-Lukes Wunsch aber auch wieder nicht. Es kann nämlich schon schlicht unpraktisch sein, dann auch mit dem Rechtsklick immer noch einmal zusätzlich exakt auf die Selektierung zielen zu müssen. Besonders, wenn die selektierte Zeile kurz ist, weil sie nur wenige und/oder schmale Buchstaben hat. Oder man hat mehrere Zeilen selektiert und es sind da ein paar (sehr) kurze dabei. Da darfst du dann beim Rechtsklick auch nicht aus Versehen mal mit der Maus in so eine "Lücke" rutschen.

Sofern eine Selektierung überhaupt da ist, sollte die bei einem Rechtsklick dann imo eben auch immer angesprochen sein. Jedenfalls ist die Konkurrenzsituation, dass man mit einem solchen danebengehenden Rechtsklick dann nämlich nicht die Selektion meint, sondern das Kontroll insgesamt, dazu ja auch eher selten (...auch schon wegen ihrer internen Doppelaktion, die Selektion zu löschen bzw. zu ändern und gleichzeitig damit dann auch noch das Kontextmenü zu starten)...

...Und irgendwelche Standard-Funktionsabläufe sollten in erster Linie aber solche Situationen unterstützen, die ein mehrheitlich klares Übergewicht haben.

Würde man tatsächlich NICHT die Selektion meinen, könnte man in solchen klar selteneren Situationen dann ja auch nochmal einen linken Zusatzklick, zum Aufheben der Selektion, verlangen. Also bloß eine zusätzliche Minimal-Aktion, die dem Handling von Selektionen dann aber durchaus wieder insgesamt mehr Eindeutigkeit und Komfort verschaffen würde.

Ergo: Kleinere Optimierungen an solchen suboptimalen DIN-Abläufen zu versuchen, ist eher legitim und macht ja den besonderen Reiz des Programmierens auch immer irgendwie etwas mit aus...


PS. Diskussionen, die in eine falsche Richtung gehen, lieber frühzeitiger als später korrigieren wollen. Das ist ja dann auch ökonomischer für alle!