| |
| |
|
| - Seite 1 - |
|
 | Meine Frage an Andreas Miethe, was richtigerweise bei funzt stehen könnte, um das Malen aller einzelnen Einträge der ListBox damit selbst zu übernehmen, dass ein hPic gezeichnet wird statt z.B. der Eintragstext. 
KompilierenMarkierenSeparierencls
var h&=create(ListBox,hWnd,0,10,10,200,200)
var hPic&=create(hNewPic,15,15,$1278FF)
subClass h&,1
addString(h&,Hallo Welt)
addString(h&,Hallo Welt2)
while 1
waitInput
wend
end
subClassProc
if &sWnd=h&
funzt
drawPic hPic
endif
endProc
|
|
| |
| |
| |
|
|
| |
| |
| - Seite 1 - |
|
Jörg
Sellmeyer | | Ok - jetzt hab ichs auch. Hatte vergessen in den Projekteinstellungen die neue Runtime anzugeben. Läuft also bis auf die Interpreter-/Runtime-Seltsamigkeit, die Du oben erwähnt hast. |
|
| |
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ...  | 22.02.2009 ▲ |
|
| |
|
|
| Das Beispiel zeigt, dass es schade ist, dass die SubClassProc nur im WaitInput greift.
Werden im Programmablauf zunächst die Listboxen erzeugt und befüllt, wonach dann die Hauptschleife mit WaitInput erreicht wird.
Weil die Nachrichten verloren sind, werden zunächst keine Items dargestellt. |
|
| |
| |
| |
|
|
| Hmpf, auch wenn ich z.B. wm_drawItem zusätzlich als UserMessage deklariere um der Hauptschleife mitzuteilen, dass in ListBoxen Einträge zu zeichnen wären, dann erhalte ich (natürlich) weder in uwnd, ulparam noch uwparam eine brauchbare Info - sodass ich neu zeichnen könnte.
Könnte man _nur innerhalb der subClassProc und innerhalb des waitInput addString anweisen sodass die Einträge auch angezeigt werden. :/
Ich teste mal, ob man wm_command als UserMessage nutzen kann - sollte ja bei lbs_notfiy versandt werden mit Handle der ListBox im ulParam.
Nachtrag: wm_command wird nicht ausgelöst von addString - ldr. (auch) keine Lösung. |
|
| |
| |
| |
|
| |
| |
| - Seite 2 - |
|
|
| | wm_compareItem wäre (halbwegs) geeignet als UserMessage, nur schade dass man dafür lbs_sort einschalten, und lbs_hasStrings abschalten müsste. :/ |
|
| |
| |
| |
|
|
Uwe
''Pascal''
Niemeier | |
| |
| |
| |
|
|
| Verstehe ich nicht ganz.  |
|
| |
| |
| |
|
|
Uwe
''Pascal''
Niemeier | Damit wollte ich andeuten, daß mein Vorschlag, SubClassing auf Wunsch von WaitInput unabhängig zu machen, durchaus sinnvoll ist, weil dies eine Erweiterung der Möglichkeiten wäre 
(Im Gegensatz zu den Vorschlägen, die nur auf Vereinfachungen abzielen)
SeeYou
Pascal |
|
| |
| |
| |
|
|
| Der Wunsch existiert aber schon lang.
Besonders, aber nicht erst seit Erfindung von subClassProc, mecker ich und wünsche hier und da einen Stack nicht nur für ProcAddr*. 
*) dürfte auch das subClassProc-Problem beheben.
Angefangen hats mit den UserMessages und mit Start/EndPaint wirds nicht enden.
Im Prinzip sind die gestackten UserMessages und die SubClassProc nur ein Workaround - es scheint wohl alles andere als einfach die procAddr-Calls zu stacken (womit alles andere unnötig wäre wie userMessages und subClassproc).
Vielleicht regt Roland genau zum Thema mal das Fachsimpeln an.
Ich kann mir zwar vorstellen wie und warum das so schwierig ist und wie man das Problem beheben könnte - aber diese Vorstellungen basieren auf einem spekulierten XProfaninnenleben. |
|
| |
| |
| |
|
|
| Zeigen sich diese Listboxen korrekt?
Ich versuche grad ob es nicht möglich ist, solche Listboxen irgendwie standardisiert mit XProfan anzuzeigen ohne Anzeigebugs.
Also
KompilierenMarkierenSeparierenReagieren die ListBoxen in der Exe korrekt und flimmern nicht? |
|
| |
| |
| |
|
|
Thomas
Freier | | Sie werden nicht immer neu aufgebaut. Besonders wenn nur der Scrollpfeil benutzt wird (Bild). Wird ein anderes Fenster darüber gezogen, wird neu aufgebaut. |
|
| |
| |
| |
|
|
Rolf
Koch | | Stimmt, genau wie Thomas sagt es wird neu gezeichnet. |
|
| |
| |
| |
|
|
| | Gut, damit sind die Möglichkeiten dahin - zuverlässige LBS_OWNERDRAWFIXED ListBoxen ohne gefährliches procAddr rein per subClassProc sind nicht möglich. |
|
| |
| |
| |
|
(1.103)
Deutsch
English
Français
Español
Italia