XProfan

- Seite 2 -

Vielleicht ein zweites GetControlParas

Frank?

Salve.

16.05.2005 ▲

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

Website: [...]

Facebook: [...]

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.