XProfan

- page 2 -

peut-être un zweites GetControlParas

Frank?

Salve.

16.05.2005 ▲

Jörg
Sellmeyer

[quote-part:92bc8dc0ae=Frank Abbing]Hi,

veux du une Dll-Version sans?[/quote-part:92bc8dc0ae]
[AUFSPRING_HUEPF]je veux aussi une!![/AUFSPRING_HUEPF]

Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...

16.05.2005 ▲

ByteAttack

alors si Du qui Messages

eh pas pour nötig hälst, schmeiß vous doch generell aus qui ListView.dll

raus - ou bien

Website: [...]

Facebook: [...]

qui Message hat sicherlich ses Berechtigung - c'est pourquoi mon je oui es wäre peut-être sinnvoll de Frank simple un zweites GetControlParas

trop erfinden.

ou bien il baut une Stopper - quel avant Getmessage

gelegt serait.

Salve.

Frank
Abbing

Hi,

qui Message verwende je à verschiedenen se mettre dans qui Dll et generell ist vous très sinnvoll et sogar sans cesse. seulement à cette Stelle ginge es aussi sans.
iFs Schalteridee finde je mais encore besser, tout autor werde je cet la fois ab Version 1.7 einbauen

Marc-Gordon: je personnelle serait toujours WaitInput avec Minuteur verwenden, anstatt GetMessages. avec cela J'ai eu bisher nie irgendwelche Probleme, et je nutze es wirklich souvent...

Waitinput avec Minuteur mais est mais plutôt pas empfehlenswert - bedenke on - cela toujours qui Messages geklaut volonté. quand De toute façon je nen Minuteur einsetzte - ensuite ging z.B. cela schließen seulement encore trop 99% - presque indépendant vom Timerwert. cela Timernutzen finde je ist vraie ne Notlösung. c'est pourquoi habe je oui qui Fil.Pcu

geschrieben - là gibts aucun Messageklauereien plus - et il peut soviel timen comment on veut - aussi avec très très kleinen Timerwerten im Echtzeitbereich.

Salve.

Frank
Abbing

Hi,

j'ai qui annoncé Funktion incorporé. dans qui prochain Version wird vous zur Disposition stehen:

ForbidScrollMessage(F)

Verhindert cela automatische Scrollen de seulement zum partie sichtbaren Items.

F : Long - Flag

à einigen se mettre verwendet qui Listview.dll une Message, quelle seulement partiellement sichtbare Einträge komplett dans cela Listview einschiebt.
cela peux mais hin et wieder trop ungewollten Verschiebungen mener, nämlich toujours ensuite, si dans qui Message-Boucle pas Waitinput benutzt wird. Betroffen hiervon sommes ensuite qui Funktionen SelectLine(), GetControlParas() et GetOwnControlParas().
ForbidScrollMessage() ist en supplément gedacht, cela automatische Sichtscrolling kurzfristig auszuschalten, si cet Funktionen im Programme benutzt volonté et qui Message-Boucle ne...aucune WaitInput beinhaltet. Kurzfristig deswegen, weil qui betroffene Message nämlich aussi im Éditer- et Drag&Drop Modus benutzt wird et im ausgeschalteten Zustand ansonsten très unerwünschte Effekte produzieren wird!
F=0 ist qui Normalzustand. Ist F=1, ensuite ist cela Autoscrolling deaktiviert.

ForbidScrollMessage(1)
y&=Getcontrolparas(bereich#)
ForbidScrollMessage(0)
Si y&<>0
...

> Waitinput avec Minuteur mais est mais plutôt pas
> empfehlenswert - bedenke on - cela toujours
> qui Messages geklaut volonté. quand De toute façon
> je nen Minuteur einsetzte - ensuite ging z.B.
> cela schließen seulement encore trop 99% - presque indépendant
> vom Timerwert. cela Timernutzen finde je
> ist vraie ne Notlösung. c'est pourquoi habe je
> oui qui Fil.Pcu

geschrieben - là
> gibts aucun Messageklauereien plus - et
> il peut soviel timen comment on veut - aussi
> avec très très kleinen Timerwerten im Echtzeitbereich.

Threads sommes ici mais aussi pas qui Ideallösung, là vous un Programme doch stark abbremsen. chez einem zusätzlichen Fil hat mon Hauptprogramm seulement encore 50% Power. chez deux Threads gar seulement 33% usw.
mon Programme avec Timern travailler sowieso moins avec Messages, et si, ensuite nutze je qui Usermessages, qui dans chaque le cas durchkommen (siehe mon SpriteRotator) ou bien encore besser mon Message.dll, qui im Subclassing steckt et chacun encore so kleine Message registriert. qui Dll halte je personnelle pour qui Ideallösung...

Ist zwar offtopic - mais chez qui Fil.Pcu verhält es sich anders. je integriere Threads dans Callbacks - mets par-dessus encore une intelligente Verwaltung - et cet handelt qui Fil.Do. chez gekonnter Handhabung dedans qui Fil.Do par den Programmierer ist qui zusätzliche Prozessorlast absolu unerheblich - sozusagen à peine spürbar. qui Kunst bestand arrêt y qui Possibilité trop créer - dans XProfan Threadähnlich programmieren trop peut - avec dem Vorteil cela alles dedans des eigenen Programmes passiert - um z.B. aussi sur alle Variablen/Prozeduren zurückgreifen trop peut. qui Fil.Pcu ist alors plutôt un très gelungener et fehlerfreier couloir sur Messers Schneide - et une reine Vorteilsmaschine. :/:

Salve.