Hallo NG!

Ich möchte in meine Textbox alle Zeichen hineinschreiben können. Das geht
ja, wenn ich die Schriftart wähle und dann auswähle, ob ich es Westlich,
Griechisch, ... haben möchte. Aber ist es möglich die Textbox als Unicode zu
formatieren, wenn ja wie? Wenn nicht, gibt es dann Auswegsmöglichkeiten?

Mit freundlichen Grüßen

"Karl M." <KarlM> schrieb:
> Ich möchte in meine Textbox alle Zeichen hineinschreiben können. Das geht
> ja, wenn ich die Schriftart wähle und dann auswähle, ob ich es Westlich,
> Griechisch, ... haben möchte. Aber ist es möglich die Textbox als Unicode
> zu
> formatieren, wenn ja wie? Wenn nicht, gibt es dann Auswegsmöglichkeiten?

Nicht direkt. VB benutzt die ANSI-Versionen der Windows-Steuerelemente. Man
müsste vermutlich mit Win32-API-Aufrufen entsprechende Unicode-fähige
Fensterklassen instanzieren (aufwendig).

Ich hab ein paar Versuche mit dem Control "RichTextBox" gemacht. Es
funktioniert mit Westlich, Grieschisch, etc.
Was ist davon zu halten? Gibt es Gegenargumente bei der RichTextBox?

Mit freundlichen Grüßen

Ich arbeite zurzeit an einer Unicode-TextBox, sie wird aber noch ein
paar Wochen brauchen, da ich momentan kaum Zeit habe. Wenn Du an einer
Vorabversion interessiert bist (das meiste geht schon), sag einfach
Bescheid.

Timo

Hallo Timo,

das ist ein nettes Angebot, doch benötige ich nicht nur TextBoxen, sondern
auch Labels, Grids, Listviews, ComboBoxen, ... imprinzip alle gängigen
Controls und sie müssen letztlich alle Unicode unterstützen.

Hast du oder einer der Leser dieses Postings noch eine Idee, wie ich das
lösen kann?

Mit freundlichen Grüßen

An Unicode-fähigen Controls hätte ich noch zu bieten:
- TreeView
- ListView
- CommandButton
- CheckBox
- OptionButton
- Frame
- StatusBar
- TabStrip
- TrackBar
(- Animation)
(- ProgressBar)
Und bald:
- IPAddressBox
- HotKeyBox
- UpDownTextBox

Wenn Du Unicode-Zeichen anzeigen willst, kommst Du um Unicode-fähige
Controls nicht wirklich herum. Bei einigen Controls hilft es angeblich,
SubClassing zu nutzen und dabei die Unicode-APIs zu verwenden, also
SetWindowLongW und CallWindowProcW.

Wenn Du volle Unicode-Unterstützung benötigst, empfiehlt sich ein
Umstieg auf VB.net.

Timo

Die Möglichkeit mit dem SubClassing mittels Unicode-API hört sich interessant
an. Wie wäre das möglich? Wäre es möglich eine Schleife ins Form-Load zu
setzen, die dann alle Controls durchgeht und mit SubClassing verseht?

Mit freundlichen Grüßen

Ich hatte es mal hinbekommen, dass das TreeView der MS Common Controls
5.0 Unicode-Text anzeigt. Dazu habe ich für das SubClassing
SetWindowLongW verwendet und soweit ich mich erinnern kann sämtliche
Nachrichten per CallWindowProcW an die alte Fensterprozedur
weitergeleitet. Evt. habe ich auch noch das Elternfenster "gesubclassed"
und bei der Nachricht WM_NOTIFYFORMAT NFR_UNICODE zurückgegeben, so
genau weiß ich das nicht mehr.
Das Problem an der Sache: Ich wurde seitdem schon mehrfach gefragt wie
das geht, bekomme es aber partout nicht mehr hin und den Code von damals
habe ich nicht mehr. Möglicherweise funktioniert das durch irgendeinen
Windows-Patch nicht mehr.
Prinzipiell sollte es aber möglich sein, denn unter Windows NT sind
intern alle Fenster Unicode-fähig.

Timo

"Karl M." <KarlM> schrieb im Newsbeitrag
news:148d

> ...doch benötige ich nicht nur TextBoxen, sondern auch Labels,
> Grids, Listviews, ComboBoxen, ... imprinzip alle gängigen
> Controls und sie müssen letztlich alle Unicode unterstützen.

Wenn Du noch zwei, drei Wochen wartest, dann bin ich mit
meinem Nachbau der VB-Standard-Controls fertig (TabControl,
ToolBar, StatusBar und Progressbar sind in dieser ersten Version
auch noch mit dabei).

Die können dann sämtlich UniCode, unterstützen Transparenz- und
Alpha-Transparenz (auch die TextBox und das Frame-Control).
Hover-Effekte sind ebenfalls implementiert - Abhängigkeiten von
Windows-Fensterklassen oder gar den Windows-CommonControls
bestehen keine (alles wird mittels Standard-GDI-API selbst gezeichnet).
Sämtliche Attribute sind ohne irgendwelche Verrenkungen zur Laufzeit
umschaltbar (z.B. TextBox-Multiline u.ä.).
Alles, bis auf das Frame-Control (Container) ist als WindowLess-
Control implementiert - d.h. Null! Handle-Verbrauch, weder hWnds
(klar) noch GDI-Handles, was ein ziemlich guter Multiplikator ist
;-), wenn man die Verschaltung dieser Basis-Steuerelemente zu
selbstentwickelten, komplexeren Controls in Betracht zieht.
Ausser entsprechend mehr Speicherverbrauch passiert da also nicht
wirklich was hinsichtlich knapper Ressourcen (max. hWnd-Count liegt
bei XP ja bei 10.000 systemweit und GDI-Handles bei 10.000/Prozess
und 50.000 systemweit).
So lassen sich z.B. 500 CommandButtons per Controls.Add in nur
0.4 sec (gemessen auf PIV 2.6GHz) laden und ziehen dann insgesamt
so um die 900kByte Speicher (also ca. 2kB pro Control).

Bei der Gelegenheit (bevor ich das Binary kostenlos online stelle)
gleich noch eine Frage an die Gemeinde:
Bzgl. des Stils hab' ich versucht so ein "Mittelding" aus den bekannten
XP-Themes nachzuempfinden (recht seriös, die Farbverläufe sind mehr
so "Grau in Grau" gehalten), das Layout sticht also bei keinem der XP-
Stile besonders heraus (am unauffälligsten sieht es unter dem XP-Silver-
Theme aus). Man kann die Basis-Farbe auch in gewissen Grenzen
einstellen auf leicht bläuliche oder von mir aus auch grünliche Grau-
Verläufe). Eine 'Appearance'-Property habe ich hinsichtlich binär-
kompatibler Updates schon mal überall eingebaut aber mehr im Hinblick
auf schnelle Reaktion hinsichtlich irgendwelcher neuer, möglicherweise
"abartiger" (im Sinne von "aus der Art schlagender") Vista-Styles.
Die Frage ist, wie wichtig wäre Euch beim Blick in die entgegengesetzte
Richtung die Unterstützung der alten VB- bzw. Win98/W2K-Stile?
Muss ich mich wirklich dranmachen und den Drawing-Code auch für
die alten Styles auslegen - oder stört Euch als potentielle Nutzer das eher
wenig, wenn die Anwendung auch im Win-Classic-Theme bzw. unter
Win98/W2K wie gesagt, nicht bonbonfarben, aber schon ziemlich
nach XP-Stil aussieht?
Wäre auch vorab an Anregungen interessiert, was alles "unbedingt noch
rein soll" (noch ist die Baustelle offen und Binärkompatibilität kein
Thema).
Da ja kein hWnd-SubClassing gegen die Controls möglich ist, habe ich z.B.
in die List- und die ComboBox schonmal vorsorglich ein 'OwnerDraw'-
Event eingebaut, die TextBox und die Listen haben jeweils eine 'RowHeight'-
Property, es gibt VerticalAlignment für alle Controls ... also in der
Richtung
werden spezielle Wünsche, die irgendwo auf den zweiten Blick dann doch
Sinn machen, gern mit eingebaut, oder doch zumindest in den Schnittstellen
schonmal vorgesehen.

Olaf

Schmidt schrieb:
> Hover-Effekte sind ebenfalls implementiert - Abhängigkeiten von
> Windows-Fensterklassen oder gar den Windows-CommonControls
> bestehen keine (alles wird mittels Standard-GDI-API selbst gezeichnet).
IMHO ein klarer Nachteil. ;) Würden sie auf den nativen Fensterklassen
basieren, müsstest Du bspw. nicht unbedingt für Vista neue Versionen
rausbringen, sondern man könnte die neuen Features von Vista mithilfe
von Fensternachrichten u. ä. aktivieren.

> Bei der Gelegenheit (bevor ich das Binary kostenlos online stelle)
> gleich noch eine Frage an die Gemeinde:
> Bzgl. des Stils hab' ich versucht so ein "Mittelding" aus den bekannten
> XP-Themes nachzuempfinden (recht seriös, die Farbverläufe sind mehr
> so "Grau in Grau" gehalten), das Layout sticht also bei keinem der XP-
> Stile besonders heraus (am unauffälligsten sieht es unter dem XP-Silver-
> Theme aus). Man kann die Basis-Farbe auch in gewissen Grenzen
> einstellen auf leicht bläuliche oder von mir aus auch grünliche Grau-
> Verläufe). Eine 'Appearance'-Property habe ich hinsichtlich binär-
> kompatibler Updates schon mal überall eingebaut aber mehr im Hinblick
> auf schnelle Reaktion hinsichtlich irgendwelcher neuer, möglicherweise
> "abartiger" (im Sinne von "aus der Art schlagender") Vista-Styles.
> Die Frage ist, wie wichtig wäre Euch beim Blick in die entgegengesetzte
> Richtung die Unterstützung der alten VB- bzw. Win98/W2K-Stile?
> Muss ich mich wirklich dranmachen und den Drawing-Code auch für
> die alten Styles auslegen - oder stört Euch als potentielle Nutzer das eher
> wenig, wenn die Anwendung auch im Win-Classic-Theme bzw. unter
> Win98/W2K wie gesagt, nicht bonbonfarben, aber schon ziemlich
> nach XP-Stil aussieht?
IMHO sollte jede Software sich an die Designvorgaben des Betriebssystems
halten, was mit GDI-Nachbauten fast unmöglich ist. Spätestens, wenn
versucht wird, den XP-Stil ohne Verwendung des Theming-APIs nachzubauen,
wird es grausig.
So wie es klingt, greifst auch Du nicht auf das Theming-API zurück. Nimm
mal Deine Controls, installiere ein Nicht-Standard-XP-Theme und schau
wie es aussieht. ;)

Ich zeichne bei meinen Controls an exakt einer Stelle das Control selbst
(unter Verwendung des Theming-API): Das Frame-Control für den Fall, dass
die comctl32.dll 6.x genutzt wird. Denn in diesem Fall hatte ich ein
starkes Flackern, welches ich bis heute nicht anders beseitigen kann.
Allerdings habe ich unzählige Tests gefahren, um sicherzustellen, dass
das Control auch wirklich 100% so aussieht wie von der comctl32.dll
selbst gezeichnet. Und sobald es mir gelingt, das Flackern zu
beseitigen, fliegt der Code wieder raus.

Just my 0,02 ¤
Timo

"Timo Kunze" <TKunze71216> schrieb im Newsbeitrag
news:a644
> Schmidt schrieb:
> > Hover-Effekte sind ebenfalls implementiert - Abhängigkeiten von
> > Windows-Fensterklassen oder gar den Windows-CommonControls
> > bestehen keine (alles wird mittels Standard-GDI-API selbst gezeichnet).
> IMHO ein klarer Nachteil. ;)
Irgendwo muss der Ansatz ja einen haben. ;-)
Hab' an der Stelle auch ziemlich lange hin- und herüberlegt - mich dann
aber für die "größeren Freiheitsgrade" entschieden.
Beim GDI-Ansatz hat man alles unter Kontrolle - keine Überraschungen
möglich, weder unter Linux/Wine, noch unter Win98 - die Anwendung
sieht überall gleich "modern" aus. Der Einsatz der uxTheme.dll für das
Zeichnen der Control-Oberflächen steht mir bei meiner Herangehensweise
ja ausserdem immer noch frei.
Wichtiger für die Erst-Inkarnation ist mir erstmal der geringe Ressourcen-
Verbrauch und der Verzicht auf jegliche Abhängigkeiten gewesen (Wine
immer im Auge behaltend). Dann eine möglichst hohe Stabilität (das
Ganze ist "End-Knopf-Save" in der IDE - auch bei Private-Einbindung
der Controls). Das Projekt enthält keine einzige Zeile SubClassing- oder
Hooking-Code, nur zwei Hand voll GDI-API-Declares..

> Würden sie auf den nativen Fensterklassen
> basieren, müsstest Du bspw. nicht unbedingt für Vista neue Versionen
> rausbringen, sondern man könnte die neuen Features von Vista mithilfe
> von Fensternachrichten u. ä. aktivieren.
Bei beiden Ansätzen hat man entspr. Coding-Aufwand bzgl. der
einzubauenden Weichen. Auf der einen Seite muss man auf untersch.
Versionen/Möglichkeiten der comctl32/uxTheme-Dlls Rücksicht nehmen
- und in meinem Fall muss ich halt den Drawing-Code in Abhängigkeit
der Appearance-Property anpassen - und der ist so strukturiert, dass ich
künftig nicht gar so riesigen Aufwand mit eventuell anstehendem Themeing-
Support haben werde.

> IMHO sollte jede Software sich an die Designvorgaben des
> Betriebssystems halten, was mit GDI-Nachbauten fast unmöglich ist.
Also mit einem GDI-Nachbau ist absolut alles möglich - nur eine Frage
des Arbeitsaufwands. Und der ist nicht gar so hoch, wie man vielleicht
denkt. Die Codezeilen, die sich mit dem Zeichnen des derzeitigen
Standard-Themes beschäftigen, machen vielleicht 5-7% des gesamten
Projekts aus, mehr nicht (leider, denn das ist eigentlich das, was richtig
Spass macht - der Rest ist hauptsächlich "schnöde Property-Tipperei".

> Spätestens, wenn versucht wird, den XP-Stil ohne Verwendung
> des Theming-APIs nachzubauen, wird es grausig.
Warum? Was ist so kompliziert daran?
Nun warte doch erstmal ab, bis ich eine erste Demo poste. ;-)

> So wie es klingt, greifst auch Du nicht auf das Theming-API zurück.
> Nimm mal Deine Controls, installiere ein Nicht-Standard-XP-Theme
> und schau wie es aussieht. ;)
Nun anders halt, aber immer noch "modern" (zumindest werden die
Unterschiede geringer ausfallen als bei einer "OldStyle"-VB-App).
Ich meine, das neue MS-Office malt auch viele Dinge anders hin, als
man das so kennt - trotzdem finden es die Meisten toll und kommen
problemlos mit der Bedienung zurecht. Die Nutzer sind durch das
Surfen auf unterschiedlichst designten WebSites diesbezüglich eh nicht
mehr soo empfindlich wie vielleicht noch zu Win95-Zeiten.
Solange Scrollbars nicht diagonal bedient werden müssen und Buttons
nicht selbständig vor der Maus flüchten, kann den heutigen User doch
eigentlich nix großartig mehr erschüttern.
Nahezu jedes Progrämmchen vom Schlage einer "Personal Firewall"
kommt doch heutzutage "in schick" und hält sich an überhaupt gar kein
Themeing oder gar Standard-GUIdelines.
Von solchen übertriebenen Spielereien ist mein Ansatz weit entfernt.

> Ich zeichne bei meinen Controls an exakt einer Stelle das Control selbst
> (unter Verwendung des Theming-API): Das Frame-Control für den Fall,
> dass die comctl32.dll 6.x genutzt wird. Denn in diesem Fall hatte ich ein
> starkes Flackern, ...
Das sind so die Überraschungen, die beim "Zu-Fuß-Ansatz" erst gar nicht
auftreten können. Man fragt sich an keiner Stelle "warum klappt das nicht -
ich hab' doch eigentlich die korrekte Message geschickt und im Notify das
Flag xy beachtet, und, und ... - man schreibt neue Features einfach hin.

> Just my 0,02 ¤
Jo, Danke fürs Feedback, auch wenn wir wahrscheinlich nie heiraten
werden - aber Konkurrenz belebt ja bekanntlich das Geschäft. ;-)

BTW - auf Deiner Seite hab' ich gelesen, dass Du Dich auch mit Wine
beschäftigst (im ReactOS-Forum hab' ich auch schon Beiträge von Dir,
gesehen glaub' ich) - nur interessehalber (noch keine Zeit für entspr.
Tests)
wie ist denn bei den Windows-"Emus" inzwischen der Stand bzgl. XP-
Themeing-Support und den erweiterten Features der Common-Controls?

Olaf

Hallo Olaf!

Chapeau! Der einzig vernünftige Weg. Kurz vorab was mir so einfällt,
später mehr:

Du hast natürlich recht mit dem modernen Stil. MS führt den ständig in
zb Office und vor allem in Programmen wie MS Money ein, stellt ihn nicht
allgemein zur Verfügung und alle hecheln hinterher.

Viele neue Anwendungen (auch von MS, siehe oben) orientieren sich am
Web, sehen aus wie Webseiten. Das ist der aktuelle Stil. Daran muß man
sich messen.

Die Controls der Common Controls Dlls per VB verfügbar zu machen, ist
Unsinn. zB schon seit langer Zeit gibt es SmartUI: alle standard
controls nachgebaut, pures VB, alles ownerdrawn, alle Funktionalität
selbst geschrieben. SmartUI hat fast windowless gearbeitet: es gab ein
Basiscontrol mit Fenster, welches nur eine Hülle darstellte für alle
Controls von SmartUI (welche ihrerseits windowless waren). Das Common
Controls Replacement Project ist nicht zuletzt daran gescheitert, das MS
seine common controls immerzu ändert. Der getriebene Aufwand war
aberwitzig: tonnenweise Code und Verrenkungen, nur um die Common
Controls dll in ein VB Gewand zu zwängen. Nachprogrammieren der
Funktionalität und des GUIs wäre einfacher gewesen.

Ein windowed control container für deine windowless controls wäre
wichtig. Dein Frame control ist das?

Alle Controls sollten, soweit sinnvoll, virtuelle Datenhaltung
betreiben. Datenhaltung also getrennt von den Controls, Daten abrufbar
per Event, Interface und einbettbarer Datenklasse. Ebenso OwnerDraw
Events oder aufrufbar per Interface, wo es nur geht.

Was den Stil betrifft: einige Systembasics sollten die Controls
übernehmen, als da zB wären: Fonts, bestimmte Hintergrundfarben (wie
Controlhintergrund), Größen (zB Sliderbreite, Dropdownboxbreite, etc pp)
und noch einiges mehr. Kurz alles, was der User über die
Systemeinstellungen setzen kann und sein Motiv für Änderungen gegenüber
den Defaults handfester Art (wegen zb Sehbehinderung) ist und nicht
wegen irgendwelcher Geschmacksverirrungen (ich hätt' gern alles
lilablaßblau :-).

Die Tastaturbedienung sollte erhalten bleiben. zb Tabbing (geht auch auf
Webpages, zumindest prinzipiell), ein default Ok bzw. Cancel, shortcuts
(geht wiederum zumindest prinzipiell auch auf Webpages).

Gut, und dann wäre da noch binär oder source code. Dein Projekt sieht ja
schwer nach einem GUI framework für VB aus. Wenn es offen wäre, könnte
man noch weitere controls mit neuer Funktionalität hinzufügen. Außerdem
würde es die Mitarbeit Dritter erleichtern (mit den üblichen Vor- und
Nachteilen :-)).

Allerdings gibt es ein Problem, wenn jeder für sich kompilieren darf:
die GUIDs. In der Open Source Szene gibt es, glaub ich, keine Projekte,
die frei kompilierbare COM-Quellen haben. Zugegeben, auch bei standard
Dlls kann es Versionsproblemme geben, aber unter COM verschärft sich das.

In meinem Projekt verwende ich die MS Common Controls 6.0. Kennst du eine
Site, bei der ich mir die Informationen besorgen kann, bezüglich ansprechen
der API, SubClassing, usw. ...?

Mit freundlichen Grüßen

Mit den Common Controls 6.0 wirst Du keinen Erfolg haben.
Zum Thema Subclassing sollte Google genug Seiten ausspucken. Auf
ActiveVB gibts sicher auch ein Tutorial.

Timo

"Ulrich Korndoerfer" <ulrich_wants_nospam> schrieb im
Newsbeitrag news:0507

> Du hast natürlich recht mit dem modernen Stil. MS führt den ständig
> in zb Office und vor allem in Programmen wie MS Money ein, stellt
> ihn nicht allgemein zur Verfügung und alle hecheln hinterher.
> Viele neue Anwendungen (auch von MS, siehe oben) orientieren sich
> am Web, sehen aus wie Webseiten. Das ist der aktuelle Stil. Daran
> muß man sich messen.
Seh ich auch so - wichtig ist inzwischen für die Meisten nur noch, dass
die GUI-Elemente in ihrer Funktionalität eindeutig zuordenbar, bzw.
(bei neuartigen Controls) möglichst intuitiv erkennbar sind - und dass
natürlich das erwartete und korrekte Verhalten der Steuerelemente
hinsichtlich Tastatur- oder Maussteuerung gegeben ist (z.B. Doppelclick
auf Textbox markiert Wort - oder CommandButton anklicken - Maus
wegziehen - loslassen - kein Click-Event, usw.).

> Die Controls der Common Controls Dlls per VB verfügbar zu machen,
> ist Unsinn. zB schon seit langer Zeit gibt es SmartUI: alle standard
> controls nachgebaut, pures VB, alles ownerdrawn, alle Funktionalität
> selbst geschrieben. SmartUI hat fast windowless gearbeitet: es gab ein
> Basiscontrol mit Fenster, welches nur eine Hülle darstellte für alle
> Controls von SmartUI (welche ihrerseits windowless waren).
Hab' SmartUI nie getestet - das mit dem darunter zu platzierenden,
speziellen Container hat höchstwahrscheinlich mit dem Abgreifen der
Arrow-Keys zu tun (die werden von VB abgefangen, um so eine Art
"alternatives Tabbing" zwischen WindowLess-Controls sicherzustellen
- vielleicht aber auch wegen Transparenz-Drawing-Effekten, um so auf
den DIB-Backbuffer eines *bekannten* Containers über entspr. Methoden
immer sicheren Zugriff zu haben.
BTW - was ziehen denn z.B. 500 Textboxen von SmartUI so an GDI-
ressourcen - ohne/mit aktivierter Transparenz (bei mir aktuell 0/500).

> Ein windowed control container für deine windowless controls wäre
> wichtig. Dein Frame control ist das?
Ja (und die Standard-VB-Container gibt es ja auch noch). Ich setzte
jedenfalls (zumindest bis jetzt) keinen speziellen Container voraus.

> Alle Controls sollten, soweit sinnvoll, virtuelle Datenhaltung betreiben.
> Datenhaltung also getrennt von den Controls, Daten abrufbar per Event,
> Interface und einbettbarer Datenklasse.
Nette Anregung - muss nur schauen, wie ich das möglichst effizient mit
den (kompatibel gehaltenen) "Standard-Befüll-Methoden" unter einen
Hut bringe. Bei der List/Combobox landen die Daten z.B. derzeit in einer
VB-Collection (ItemData auch - da darf also so ziemlich alles abgeheftet
werden) - die könnte man natürlich recht einfach nach aussen
offenlegen (obwohl ich schon überlegt habe, das nochmal auf ein
String-Array umzuschreiben).

> Ebenso OwnerDraw Events oder aufrufbar per Interface, wo es nur
> geht.
Wie gesagt, bei den Listen ist sowas schon drin - bei den anderen (nicht
scrollbaren) Controls macht das derzeit nicht so recht Sinn - die sind ja
schon von Haus aus mit Up-Down-Disabled-Pictures recht gut ausgestattet.
Später dann wieder bei Tree- und ListView, klar.

> Was den Stil betrifft: einige Systembasics sollten die Controls
> übernehmen, als da zB wären: Fonts, bestimmte Hintergrundfarben (wie
> Controlhintergrund),
Die gibt ja der User vor über die entspr. bekannten Dropdowns im VBs
Property-Grid (SystemColor-Indices werden natürlich als Farben
unterstützt). Enstsprechende Initialisierung über Ambient.Font, etc. beim
ersten Aufziehen eines Controls ist natürlich drin.

> Größen (zB Sliderbreite, Dropdownboxbreite, etc pp)
> und noch einiges mehr.
Ha, Treffer - werd' ich berücksichtigen.

> Kurz alles, was der User über die
> Systemeinstellungen setzen kann und sein Motiv für Änderungen gegenüber
> den Defaults handfester Art (wegen zb Sehbehinderung) ist und nicht
> wegen irgendwelcher Geschmacksverirrungen (ich hätt' gern alles
> lilablaßblau :-).
>
> Die Tastaturbedienung sollte erhalten bleiben. zb Tabbing (geht auch auf
> Webpages, zumindest prinzipiell),
Funktioniert ohne jede Einschränkung - der Focus wird natürlich auch
visualisiert.
> ein default Ok bzw. Cancel, shortcuts
Schon alles drin.

> Gut, und dann wäre da noch binär oder source code. Dein Projekt sieht
> ja schwer nach einem GUI framework für VB aus. Wenn es offen wäre,
> könnte man noch weitere controls mit neuer Funktionalität hinzufügen.
> Außerdem würde es die Mitarbeit Dritter erleichtern (mit den üblichen
> Vor- und Nachteilen :-)).
Da muss ich mal drüber schlafen, steckt halt eine Menge Basisarbeit drin.
In meiner Denke sollte man den SourceCode preiswert erwerben können -
zusammen mit einem Progrämmchen, das aus den SourceFiles des (Public)
OCX-Control-Projekts per Knopfdruck (unter Berücksichtigung der Control-
Dependencies untereinander) ein Set aus Private-Files erzeugt, die man
dann einfach direkt in sein "Exe-Projekt" reinziehen kann.
Aber erst mal schauen, wie die Resonanz so ist - zumindest die Binaries
sollen ohne jede Einschränkung frei einsetzbar sein und das auch bleiben.

> Allerdings gibt es ein Problem, wenn jeder für sich kompilieren darf:
> die GUIDs. In der Open Source Szene gibt es, glaub ich, keine Projekte,
> die frei kompilierbare COM-Quellen haben. Zugegeben, auch bei standard
> Dlls kann es Versionsproblemme geben, aber unter COM verschärft sich das.
Dem Problem könnte man mit separat vorgehaltenen TypeLibs etwas die
Schärfe nehmen - aber im Grunde hast Du Recht - COM schreckt viele ab.

Jedenfalls erstmal Danke für das Feedback.

Olaf