| |
| |
|
| - Seite 1 - |
|
ByteAttack | Hallo Community,
ich möchte gerne den Mausklick in einem ListView auswerten.
Allerdings habe ich noch andere Abfragen laufen, sodas ein WaitInput für meine WhileNot Schleife nicht in Frage kommt. Ich muss alles mit GetMessage machen.
Beispiel:
Das funktioniert auch Prima, doch leider scrollt dann das ListView mit meinem Mauszeiger immer mit... Das geschieht mit WaitInput aber nicht  |
|
| |
| |
| |
|
| |
| |
| - Seite 2 - |
|
|
ByteAttack | Ich muss GetMessages nehmen, damit das Fenster wieder neu aufgebaut wird, wenn sich die größe ändert. Das klappt zwar auch mit Waitinput, aber leider nicht immer, da manchmal beim ändern des Fenster halt kein Waitinput für Profan stattfindet...
 |
|
| |
| |
| |
|
|
ByteAttack | Mein Gott, wie unhöfflich. Wollte allen danken, die mir geholfen haben.
Sowas... |
|
| |
| |
| |
|
|
 | Nein dann brauchst Du kein Getmessages. 
Schau Dir mal in der Bibliothek im Bereich eleganteste Lösung mein Posting an.
Dort siehst Du wie sauber es auch mit Waitinput - und zwar Live! - funktioniert.
Salve.  |
|
| |
| |
| |
|
|
Frank
Abbing | Hi,
> Bei mir scrollt die LV auch falsch. Dein Beispiel funzt - es liegt nicht am Maustreiber
> - eher daran das die messages nicht zurückgesetzt werden. Da wiederrum müsste Frank
> mal schauen wie er dies mit dem XProfan-Getmessage vereinbaren kann.
Ja, bei mir tritt das ungewollte Scrolling auch auf.
> Ich muss GetMessages nehmen, damit das Fenster wieder neu aufgebaut wird, wenn sich
> die größe ändert. Das klappt zwar auch mit Waitinput, aber leider nicht immer, da
> manchmal beim ändern des Fenster halt kein Waitinput für Profan stattfindet...
Hab mal den Test gemacht und das Subclassing nach dem ersten GetControlParas()-Aufruf mit CloseMessages() abgestellt. Und siehe da: Das komische Scrolling ist trotzdem da, obwohl die Listview.dll jetzt in keinster Weise ins Messageshandling eingreift...
Hab den Fehler also nicht im Subclassing gesucht, sondern in GetControlParas(). Dabei fiel mir die Message LVM_ENSUREVISIBLE auf, die ich verwende, um Einträge sichtbar zu machen, die nur halb im Listview zu sehen sind (wenn die User die mal angeklickt hat). Mach ich die Message weg, ist auch der Fehler weg. Die Message ist nicht unbedingt nötig. Ich kann sie weglassen.
Das Problem ist einfach, das GetControlParas() bei dir in einer Echtzeit-Schleife aufgerufen wird und die Message nun sofort anspringt, sobald der Mauszeige über so einem Eintrag schwebt 
Willst du eine Dll-Version ohne? |
|
| |
| |
| |
|
|
| |
| |
| |
| |
|
|
Jörg
Sellmeyer | [quote:92bc8dc0ae=Frank Abbing]Hi,
Willst du eine Dll-Version ohne?[/quote:92bc8dc0ae]
[AUFSPRING_HUEPF]Ich will auch eine!![/AUFSPRING_HUEPF] |
|
| |
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ...  | 16.05.2005 ▲ |
|
| |
|
|
ByteAttack | Also wenn Du die Messages  eh nicht für nötig hälst, schmeiß Sie doch generell aus der ListView.dll raus - oder |
|
| |
| |
| |
|
|
| Die Message hat sicherlich ihre Berechtigung - deshalb meine ich ja es wäre vielleicht sinnvoll von Frank einfach ein zweites GetControlParas zu erfinden.
Oder er baut einen Stopper - welcher vor Getmessage gelegt würde.
Salve. |
|
| |
| |
| |
|
|
Frank
Abbing | Hi,
die Message verwende ich an verschiedenen Stellen in der Dll und generell ist sie sehr sinnvoll und sogar unablässig. Nur an dieser Stelle ginge es auch ohne.
iFs Schalteridee finde ich aber noch besser, darum werde ich diese mal ab Version 1.7 einbauen 
Marc-Gordon: Ich persönlich würde immer WaitInput mit Timer verwenden, anstatt GetMessages. Damit hatte ich bisher nie irgendwelche Probleme, und ich nutze es wirklich oft... |
|
| |
| |
| |
|
|
| Waitinput mit Timer ist doch aber eher nicht empfehlenswert - bedenke man - das immer die Messages geklaut werden. Wann auch immer ich nen Timer einsetzte - dann ging z.B. das schließen nur noch zu 99% - fast unabhängig vom Timerwert. Das Timernutzen finde ich ist echt ne Notlösung. Deshalb habe ich ja die Thread.Pcu geschrieben - da gibts keine Messageklauereien mehr - und man kann soviel timen wie man will - auch mit sehr sehr kleinen Timerwerten im Echtzeitbereich.
Salve. |
|
| |
| |
| |
|
|
Frank
Abbing | Hi,
ich habe die angekündigte Funktion eingebaut. In der nächsten Version wird sie zur Verfügung stehen:
ForbidScrollMessage(F)
Verhindert das automatische Scrollen von nur zum Teil sichtbaren Items.
F : Long - Flag
An einigen Stellen verwendet die Listview.dll eine Message, welche nur teilweise sichtbare Einträge komplett in das Listview einschiebt.
Das kann aber hin und wieder zu ungewollten Verschiebungen führen, nämlich immer dann, wenn in der Message-Schleife nicht Waitinput benutzt wird. Betroffen hiervon sind dann die Funktionen SelectLine(), GetControlParas() und GetOwnControlParas().
ForbidScrollMessage() ist dazu gedacht, das automatische Sichtscrolling kurzfristig auszuschalten, wenn diese Funktionen im Programm benutzt werden und die Message-Schleife kein WaitInput beinhaltet. Kurzfristig deswegen, weil die betroffene Message nämlich auch im Edit- und Drag&Drop Modus benutzt wird und im ausgeschalteten Zustand ansonsten sehr unerwünschte Effekte produzieren wird!
F=0 ist der Normalzustand. Ist F=1, dann ist das Autoscrolling deaktiviert.
ForbidScrollMessage(1)
y&=Getcontrolparas(bereich#)
ForbidScrollMessage(0)
If y&<>0
...
> Waitinput mit Timer ist doch aber eher nicht
> empfehlenswert - bedenke man - das immer
> die Messages geklaut werden. Wann auch immer
> ich nen Timer einsetzte - dann ging z.B.
> das schließen nur noch zu 99% - fast unabhängig
> vom Timerwert. Das Timernutzen finde ich
> ist echt ne Notlösung. Deshalb habe ich
> ja die Thread.Pcu geschrieben - da
> gibts keine Messageklauereien mehr - und
> man kann soviel timen wie man will - auch
> mit sehr sehr kleinen Timerwerten im Echtzeitbereich.
Threads sind hier aber auch nicht die Ideallösung, da sie ein Programm doch stark abbremsen. Bei einem zusätzlichen Thread hat mein Hauptprogramm nur noch 50% Power. Bei zwei Threads gar nur 33% usw.
Meine Programme mit Timern arbeiten sowieso weniger mit Messages, und wenn, dann nutze ich die Usermessages, die in jedem Fall durchkommen (siehe mein SpriteRotator) oder noch besser meine Message.dll, die im Subclassing steckt und jede noch so kleine Message registriert. Die Dll halte ich persönlich für die Ideallösung...  |
|
| |
| |
| |
|
|
| Ist zwar offtopic - aber bei der Thread.Pcu verhält es sich anders. Ich integriere Threads in Callbacks - setze darüber noch eine intelligente Verwaltung - und diese handelt die Thread.Do. Bei gekonnter Handhabung innerhalb der Thread.Do durch den Programmierer ist die zusätzliche Prozessorlast absolut unerheblich - sozusagen kaum spürbar. Die Kunst bestand halt darin die Möglichkeit zu schaffen - in XProfan Threadähnlich programmieren zu können - mit dem Vorteil das alles innerhalb des eigenen Programmes passiert - um z.B. auch auf alle Variablen/Prozeduren zurückgreifen zu können. Die Thread.Pcu ist also eher ein sehr gelungener und fehlerfreier Gang auf Messers Schneide - und eine reine Vorteilsmaschine. :/: 
Salve. |
|
| |
| |
| |
|
(860)
Deutsch
English
Français
Español
Italia