OpenOffice.info

Verfasst: **Do, 23.12.2004 13:08**

Ich habe folgendes Problem, für das ich trotz intensiver Suche weder in den Handbüchern noch im Internet eine Lösung finden konnte. Allerdings muß ich dazu sagen, dass ich bislang unter VBA gearbeitet habe und dies mein erster Gehversuch unter ooBasic ist.

Ich habe einen Dialog mit 24 Controls. Dabei hängt gelegentlich die Aktivität eines Controls von der Einstellung anderer Controls ab (heißt: je nach dem, wie eine ComboBox eingestellt wird, ist eine andere aktiv oder nicht).
Soweit gibt es keine Probleme.
Unter VBA habe ich die Möglichkeit, dem Hintergrund eines deaktivierten Controls die Windows-Farbeigenschaft "deaktiviert" zuzuweisen, mit dem Ergebnis, dass unabhängig von den persönlichen Farbeinstellungen des Benutzers ein "schön" aussehender Dialog angezeigt wird. Ist der Dialog grau (Windows-Standard) wird auch das deaktivierte Control grau angezeigt (statt weiss). Hat der Benutzer z.B. die Windows-Darstellung "Ahorn" ausgewählt, ist der Dialog beige und auch das deaktivierte Control beige.
Unter OO habe ich bis jetzt nur die Möglichkeit gefunden, einem deaktiviertem Control eine bestimmte Farbe zuzuweisen. Gibt es eine der VBA-Methode ähnliche Möglichkeit, oder wenigstens die Möglichkeit, die aktuelle Farbe eines Dialogs oder eines Controls auszulesen, um sie dann auf ein anderes Control anwenden zu können?

Vielen Dank schon mal,
Vanished

Verfasst: **Do, 23.12.2004 16:34**

Hallo Vanished,

Ich verstehe Dein Problem, nämlich das z.B. ein solcher Code:

Code: Alles auswählen

Sub Main
DialogLibraries.LoadLibrary("Standard")
oForm = DialogLibraries.Standard.Dialog1
oDialog1 = CreateUnoDialog( oForm )
msgbox oDialog1.GetModel.GetByName("CommandButton1").Backgroundcolor
'oDialog1.execute
End Sub

keine Rückgabe für den Farbwert liefert, wenn der Button die Standardfarbe besitzt. Ich habe keine Ahnung wie Du an die Systemfarben kommst.
Wenn es im Speziellen nur um ein Textfeld geht, könntest Du dieses verstecken und für das deaktivierte Textfeld ein vertieftes Labelfeld anzeigen. Das sieht genauso aus und der Hintergrund ist automatisch in Dialogfarbe, obwohl ich jetzt garnicht sicher bin ob nicht die Hintergrundfarbe eines deaktivierten Textfeldes ein etwas helleres Grau sein müßte als die Farbe des Dialogs (bezogen auf Windows-Standard-Farbschema).

Gruß
Stephan

Verfasst: **Fr, 24.12.2004 12:14**

Das was Du so beiläufig erwähnst ("folgende Zeile gibt keinen Farbwert zurück, _wenn die Standardfarben benutzt werden_ (und nur dann!)" hat mich einen halben Tag Zeit gekostet und fast in den Wahnsinn getrieben (das steht sonst nämlich leider nirgendwo).

Ich wußte das bis gestern auch nicht bloß ich kannte .BackgroundColor und habe gemerkt das ich keine Rückgabe bekam und da war mir das Dilemma schnell klar. Es geht nämlich "konsequenterweise" auch nicht die Hintergrundfarbe in eine Variable einzulesen o.ä.. Alles natürlich nur wenn Standard vorliegt und Du die Farben nicht manuell gesetzt hast, bloß das nutzt Dir nichts, denn ich gehe eigentlich davon aus das das hier:

dass unabhängig von den persönlichen Farbeinstellungen des Benutzers ein "schön" aussehender Dialog angezeigt wird.

genau das Gegenteil von dem meint was dasteht, Du willst nämlich das das abhängig von den Einstellungen des Nutzers geht. Ansonsten könntest Du allen Steuerelemente beim Initialisieren des Dialogs eine Farbe zuweisen und hättest dann klar definierte Farben, aber das weißt Du selbst.
Ansonsten kann ich vielleicht den grundsätzlichen Tip geben das Du bei jedem Ogjekt, welches über Eigenschaften verfügt Dir diese mit:

Code: Alles auswählen

Msgbox <Objekt>.dbg_properties

anzeigen lassen kannst. Für den speziellen Fall hättest Du .BackgroundColor so gefunden:

Code: Alles auswählen

Sub Main 
DialogLibraries.LoadLibrary("Standard") 
oForm = DialogLibraries.Standard.Dialog1 
oDialog1 = CreateUnoDialog( oForm ) 
msgbox oDialog1.GetModel.GetByName("CommandButton1").dbg_properties 
End Sub

vielleicht war Dir das bekannt, ist nur ein Hinweis.

Nützt Dir denn mein Vorschlag mit dem Label-Feld etwas (geht zugegeben nicht für Kombinationsfelder und Listboxen)? Falls Du Schwierigkeiten bei der Umsetzung hast frage ruhig nochmal.
Mir fällt jetzt noch Folgendes ein:
wenn das nur unter Windows laufen können muß, wäre es möglich die Farbwerte der aktuellen Systemfarben aus der Registrierung auszulesen. Ich weiß jetzt nicht wo diese Farbwerte in der Registrierung stehen, aber das sollte zu ermitteln sein. Der Lesezugriff auf die Registrierung mittels StarBasic ist kein Problem (es gibt BeispielCode in den mitgelieferten Makros (falls Du nichts findest melde Dich ich suche das raus, im Kopf habe ich es leider nicht). Diese Lösung wäre reichlich umständlich, aber wäre genau das was Du brauchst.

Also - ich sehe keine einfache Lösung, und ja Deine Frage ist berechtigt und es ist schlecht das scheinbar nicht geht. Einzige Ursache könnte ich darin vermuten das OpenOffice zu verschiedenen Betriebssystemen kompatibel sein muß und ich weiß nicht wie das mit den Systemfarben unter Linux und MacOS geregelt ist. Zugegeben ist das nur eine Ausrede.

Tut mir leid Dir nicht helfen zu können, aber falls Du doch noch etwas findest schreib es hier ins Forum rein (auch gerne Wochen-Monate später, wenn der post wieder oben steht lese ich das dann auch)- ich werde das Gleiche tun wenn mir etwas bekannt wird.

Gruß
Stephan

Verfasst: **Fr, 24.12.2004 13:37**

Mir fällt jetzt noch Folgendes ein:
wenn das nur unter Windows laufen können muß, wäre es möglich die Farbwerte der aktuellen Systemfarben aus der Registrierung auszulesen. Ich weiß jetzt nicht wo diese Farbwerte in der Registrierung stehen, aber das sollte zu ermitteln sein. Der Lesezugriff auf die Registrierung mittels StarBasic ist kein Problem (es gibt BeispielCode in den mitgelieferten Makros (falls Du nichts findest melde Dich ich suche das raus, im Kopf habe ich es leider nicht). Diese Lösung wäre reichlich umständlich, aber wäre genau das was Du brauchst.

Das funktioniert bei mir ganz problemlos mit folgendem Code:

Code: Alles auswählen

Sub farbschema()
Dim wert(28) as String
wert(0) = "ActiveBorder"
wert(1) = "ActiveTitle"
wert(2) = "AppWorkSpace"
wert(3) = "Background"
wert(4) = "ButtonAlternateFace"
wert(5) = "ButtonDkShadow"
wert(6) = "ButtonFace"
wert(7) = "ButtonHilight"
wert(8) = "ButtonLight"
wert(9) = "ButtonShadow"
wert(10) = "ButtonText"
wert(11) = "GradientActiveTitle"
wert(12) = "GradientInactiveTitle"
wert(13) = "GrayText"
wert(14) = "Hilight"
wert(15) = "HilightText"
wert(16) = "HotTrackingColor"
wert(17) = "InactiveBorder"
wert(18) = "InactiveTitle"
wert(19) = "InactiveTitleText"
wert(20) = "InfoText"
wert(21) = "InfoWindow"
wert(22) = "Menu"
wert(23) = "MenuText"
wert(24) = "Scrollbar"
wert(25) = "TitleText"
wert(26) = "Window"
wert(27) = "WindowFrame"
wert(28) = "WindowText"
GlobalScope.BasicLibraries.LoadLibrary("ImportWizard")
alles = "Name des Elements: <Farbeinstellung>" & CHR(13) & CHR(13)
For i = 0 To 28
farbe = QueryValue(HKEY_CURRENT_USER, "Control Panel\Colors",wert(i))
alles = alles & wert(i) & ": RGB(" & farbe & ")" & CHR(13)
Next i
Msgbox (alles, 64, "aktuelle Farbeinstellungen des Systems")
End Sub

Mein System ist Windows 2000, der entsprechende Registry-Key könnte bei einer anderen Windowsversion auch anders lauten, dann müßte man erst die Windows-Version ermitteln und danach den Registry-Schlüssel festlegen.

Gruß
Stephan

Verfasst: **Fr, 24.12.2004 17:23**

Wow, da kann ich mich nur noch verneigen.

Die erste Lösung (Textfeld durch Labelfeld ersetzen) ging nicht, weil es sich um ComboBoxen handelt, die sich verändern. Zwischenzeitlich hatte ich erwogen, die Boxen nicht auf inaktiv zu setzen, sondern sie ganz verschwinden zu lassen (Höhe und Länge auf 0 setzen). Das fand ich aber auch nicht sonderlich elegant.

Deine Lösung ist definitiv die gesuchte (und in meinen Augen die Beste). Zum einen kann man gleich beim Start des Dialoges alle Farben auslesen und anschliessend mit ihnen "spielen" zum anderen bildet sie die aus VBA gewohnte Funktionalität ab - hmmm, was unter OpenSource-Freunden vielleicht kein wirkliches Argument ist.

Auf jeden Fall sollte Dein sub irgendwo dokumentiert werden, da ich kaum glauben kann, dass ich der einzige bin resp. war, der nach dieser Lösung gesucht hat.

Nochmals vielen, vielen Dank und schöne Feiertage
Vanished

Edit: Ein winzig kleiner Fehler war Dir im Beispiel noch unterlaufen (falls es hinterher noch jemand ausprobieren möchte):
in der drittletzten Zeile muß es statt

Code: Alles auswählen

alles = alles & wert(i) & ": RGB(" & farbe & ")" & CHR(13)

Code: Alles auswählen

alles(i) = alles & wert(i) & ": RGB(" & farbe & ")" & CHR(13)

heissen.

Verfasst: **Fr, 24.12.2004 18:19**

Auf jeden Fall sollte Dein sub irgendwo dokumentiert werden, da ich kaum glauben kann, dass ich der einzige bin resp. war, der nach dieser Lösung gesucht hat.

Halte ich für überflüssig, da bekannt ist das aus der Registierung gelesen werden kann und das Auslesen der Farben ist nur eine von tausenden Möglichkeiten.

Edit: Ein winzig kleiner Fehler war Dir im Beispiel noch unterlaufen (falls es hinterher noch jemand ausprobieren möchte):
in der drittletzten Zeile muß es statt
Code:

alles = alles & wert(i) & ": RGB(" & farbe & ")" & CHR(13)

Code:

alles(i) = alles & wert(i) & ": RGB(" & farbe & ")" & CHR(13)

heissen.

Nö,
wenn Du das so schreibst hast Du eine Feldvariable mit 29 Feldern, von denen keines dem entspricht was Du mit Msgbox ausgeben willst, außerdem kann alles nicht gleichzeitig Variable und Feldvariable sein. Das ich das als ausgabe mit MsgBox gemacht habe geschah nur zu Demonstrationszwecken. Deine ergänzung ist selbst dann falsch wenn Du andeuten wolltest die einzelnen Werte jeweils in ein Feld einzulesen, denn in den Feldern steht ja nun immer Überschrift und Wert. (aber Du bekommt wegen alles() und alles ohnehin eine Fehlermeldung, so das diese Betrachtungen hypotetisch sind)

Gruß
Stephan

Verfasst: **Sa, 25.12.2004 00:03**

Da muß ich Dich leider korrigieren.

Ok, dann erklär mir das mal denn ich verstehe es nicht und es scheint mir insgesamt sehr "merkwürdig" zu sein. So ist die Situation:

(1)
Ich beende OpenOffice auch den Schnellstarter und starte dann OpenOffice neu in dem ich ein leeres Dokument erzeuge z.B. Textdokument. Ich kopiere meinen Orginalcode in ein leeres Modul des Dokuments und starte ihn. Das Ergebnis ist so wie Du es beschreibst. Starte ich den Code gleich anschließend nochmals ist das Ergebnis aber in Ordnung.
(2)
Ich beende OpenOffice wiederum völlig (!) und wiederhole das ganze wie oben beschrieben allerdings mit der geänderten Zeile. Beim erstmaligem Starten ist der Fehler exakt der selbe wie bei meinem Orginalcode. Beim zweiten Starten ist das Ergebnis OK.

Schlußfolgerung:
Du hast meinen Code einmal laufen lassen und es ging nicht. Dann hast Du die Zeile geändert und es nochmal laufen lassen und es ging. Das liegt aber, meiner Meinung nach, nicht an dem Code sondern das es schon einmal mit dem Orginalcode lief.

Würdest Du das soweit bestätigen?
Ich weiß allerdings nicht woran das liegt.

Meine Kritik/mein Unverständnis Deines Code ansich:

Code: Alles auswählen

alles(i) = alles & wert(i) & ": RGB(" & farbe & ")" & CHR(13)

ist die Tatsache das alles eimal Feldvariable und einmal 'normale' Variable ist, denn schon diese Kontruktion funktioniert nicht:

Code: Alles auswählen

option explicit

Sub Main
Dim alles
Dim alles(28)
End Sub

Mir ist absolut nicht klar warum es so überhaupt funktioniert (das es funktioniert habe ich jetzt getestet), bloß der Fehler wird nicht durch die geänderte Zeile behoben sondern dadurch das Dein oder mein Code mindestens zweimal hintereinander gestartet wird.

Also wäre ich sehr daran interesssiert zu erfahren ob Du eine Erklärung hast warum es keine Konflikte zwischen alles() und alles in Deinem Code gibt, alles andere ist jetzt zunächst nebensächlich aber hast Du dafür eine Erklärung ich bin völlig ratlos.
Mir ist klar das es deshalb funktioniert weil der Interpreter offensichtlich nicht zwischen alles() und alles unterscheidet, nur wie kann das sein?

Nach der Änderung steht in jeder Variable der zutreffende Wert.

Dir ist aber schon klar das bei Deinem Code dann jedes Feld alles(i) für i=0 bis 28 genau den gleichen Inhalt hat und das dieser Inhalt die gesamten Informationen als Textverkettung enthält.

Trotzdem denke ich, kann eine Doku nicht schaden. Ich werde nicht der einzige sein, der versagt von meinem Problem auf die Registry zu kommen.

Wenn es nur um die Registry ansich geht ist das in Der StarBasicFAQ bereits dokumentiert, der Link steht ganz oben in diesem Forum unter "Hinweise zur Starbasic-Programmierung"

Gruß
Stephan

Verfasst: **Sa, 25.12.2004 11:15**

Hallo ihr beiden,

ich kann zwar alle eure Widersprüche nicht auflösen, aber ein paar Hinweise geben:
1. Das Phänomen des zweimaligen Aufrufes des Makros, damit die Werte richtig angezeigt werden, ist interessant. Es schein so, als dass die Bibliothel "ImportWizard" noch nicht zur Verfügung steht. Ich habs mit einem Wait(1000) probiert, das reicht aber nicht. Ich denke, hier gibt es tatsächlich einen Bug?
Lösen lässt sich das Problem durch Trenen der Aufrufe in Zwei eigenständige Subs, dann ist die Bibliothek global auch verfügbar:

Code: Alles auswählen

sub init
  GlobalScope.BasicLibraries.LoadLibrary("ImportWizard")
  farbschema
end sub

sub farbschema
....

2. Die andere Problematik: Da hat Stefan recht, alles(i) wird vom Interpreter gleichgesetzt mit alles. Da ein Array immer explizit definiert werden muss (mit DIM) , kann der Interpreter mit der in Klammern übergebenen Parametern nicht anfangen und überliest dies einfach.

Naja, vielleicht hilft es.

Schöne Grüße
Thomas

Verfasst: **Sa, 25.12.2004 12:51**

Stephan hat geschrieben: Schlußfolgerung:
Du hast meinen Code einmal laufen lassen und es ging nicht. Dann hast Du die Zeile geändert und es nochmal laufen lassen und es ging. Das liegt aber, meiner Meinung nach, nicht an dem Code sondern das es schon einmal mit dem Orginalcode lief.

Würdest Du das soweit bestätigen?

Deine Schlußfolgerung ist 100% richtig.

Was das übrige angeht habe ich ja bereits eingangs geschrieben, dass das meine ersten Gehversuche unter StarBasic sind. Insofern verstehe ich zwar Eure Argumentation, kann aber nicht wirklich mitreden. Wie erwähnt möchte ich einen VBA-Dialog portieren, leider ohne die Zeit zu haben, zuerst StarBasic lernen zu können. Also ist es mehr ein learning by doing. Immer wenn ich nicht weiterweiß, muß das Programmierhandbuch herhalten, danach Google. Und da bin ich echt dankbar, dieses Forum gefunden zu haben.

Insofern war mir schon bekannt, wie man die Eigenschaften eines Objektes ausliest (und auch, dass man die Registry auslesen kann (steht ja gleich im ersten Beitrag des Forums)) allerdings funktionierte dann bei der Umsetzung bekanntlich ja die "BackgroundColor"-Eigenschaft nicht wie erwartet.

Was die alles-Variable angeht, werdet ihr Recht haben. Aber ein "Array nicht definiert"-Fehler bei der Ausführung wäre nicht falsch, oder?

Da mein Dialog anschliessend aber nicht auf Windows beschränkt sein soll, habe ich zwischenzeitlich die Funktion zur Bestimmung des verwendeten Betriebssystems auch schon gefunden (GetGUIType; obwohl sie offensichtlich auslaufen soll).

Nochmals vielen Dank für Eure Hilfe, die ich hoffentlich auch in Zukunft noch in Anspruch nehmen darf.
Vanished

Verfasst: **Sa, 25.12.2004 15:13**

Hallo Thomas,

Lösen lässt sich das Problem durch Trenen der Aufrufe in Zwei eigenständige Subs, dann ist die Bibliothek global auch verfügbar:
Code:
sub init
GlobalScope.BasicLibraries.LoadLibrary("ImportWizard")
farbschema
end sub

sub farbschema
....

Danke, das ist zumindest eine Lösung (habe es aber nicht ausprobiert). Ich nehme jedoch an das Du einen Grund für dieses Verhalten auch nicht kennst.

Da ein Array immer explizit definiert werden muss (mit DIM) , kann der Interpreter mit der in Klammern übergebenen Parametern nicht anfangen und überliest dies einfach.

Das ich Arrays (auch ohne Option explicit) immer als solche deklarieren muß, so das solcherlei Effekte wie in dem Thread hier beschrieben ausbleiben ist mir esrst jetzt bewußt geworden (Pitonyak (S.33): You must declare array variables before using them, even if you don’t use “Option Explicit.”) - ich hätte eine Fehlermeldung erwartet, aber die kommt ebend nicht.
Keine Frage man soll sich an das erste "Programmierergebot" halten ("Du sollst Option explicit verwenden"), also man sollte immer deklarieren.

@Vanished

Nochmals vielen Dank für Eure Hilfe, die ich hoffentlich auch in Zukunft noch in Anspruch nehmen darf.

Ja, dafür ist das Forum da und ich diskutiere gerne etwas verzwickte SAchen, da ich dadurch lerne.

Gruß
Stephan

Verfasst: **So, 26.12.2004 11:00**

Hallo Stephan,

...Ich nehme jedoch an das Du einen Grund für dieses Verhalten auch nicht kennst.

Nein. Ich nehme sogar an, dass es sich um einen Bug handelt.
Vorstellen könnte ich mir folgendes: der Interpreter geht ja in 2 Stufen vor: erst wird das Modul (die Funktion) übersetzt (kompiliert), dann Zeile für Zeile ausgeführt. Während der Übersetzung werden bereits externe Resourcen eingebunden, zu diesem Zeitpunkt aber steht die Bibliothek nohc nicht zur Verfügung. Diese wird erst während der Ausführung geladen, fehlt aber während der Kompilation. Da sie resistent und global geladen wird, steht sie für alle weiteren Funktionen zur Verfügung.......
Das zumindest wäre eine Erklärung.

Gruss
Thomas

Verfasst: **So, 26.12.2004 12:42**

Das zumindest wäre eine Erklärung.

nachdem ich es überschlafen habe versuche ich mal eine andere zu geben:

In der Blibliothek "ImportWizard" gibt es im Modul "API" diese Deklaration:

Code: Alles auswählen

Public Const HKEY_CURRENT_USER = &H80000001

Hier erfolgt sowohl Deklaration als auch Wertzuweisung, letzteres scheint wohl wesentlich zu sein. Da ich zu bequem bin über die Zusammenhänge nachzudenken (wahrscheinlich müßten die Deklarationen einfach vor den DLL-Aufrufen stehen oder/und auch Global statt Public) hilft es jedoch diese Deklaration zu "umgehen":

Damit das Makro mit einmaligem Aufruf funktioniert reicht es:

Code: Alles auswählen

farbe = QueryValue(HKEY_CURRENT_USER, "Control Panel\Colors",wert(i))

in:

Code: Alles auswählen

farbe = QueryValue(&H80000001, "Control Panel\Colors",wert(i))

zu ändern.

Ich hoffe Du kannst das nachvollziehen, bei mir geht es so.

P.S.
Kennt Du eine Möglichkeit die OpenOffice-Bibliotheken zu bearbeiten ohne im Verzeichnis share\basic mit einem Editor in den Dateien zu "stochern"? Ich kann die Bibliotheken zwar ex- und importieren (und zwischenzeitlich ändern) aber vielleicht geht das auch anders?

Gruß
Stephan

Verfasst: **Mo, 27.12.2004 16:16**

Edit: upppps, letzten Beitrag von Thomas übersehen... Insofern erübrigt sich der Rest meines Textes eigentlich. Jetzt funktioniert alles prima.

Nochmals vielen Dank!

Toxitom hat geschrieben:Hallo ihr beiden,

ich kann zwar alle eure Widersprüche nicht auflösen, aber ein paar Hinweise geben:
1. Das Phänomen des zweimaligen Aufrufes des Makros, damit die Werte richtig angezeigt werden, ist interessant. (...)
Lösen lässt sich das Problem durch Trenen der Aufrufe in Zwei eigenständige Subs, dann ist die Bibliothek global auch verfügbar:
Code: Alles auswählen
sub init
  GlobalScope.BasicLibraries.LoadLibrary("ImportWizard")
  farbschema
end sub

sub farbschema
....
Schöne Grüße
Thomas

Hallo ihr beiden,

ich habe heute Eure Lösungen in meinen Dialog eingearbeitet. Funktioniert soweit wunderbar, allerdings ist die hier im Zitat nochmal wiederholte Vermutung, dass das Verteilen des Auslesens auf zwei Subs etwas helfen könnte, nicht in Erfüllung gegangen. Nach einem Neustart von OpenOffice ist beim ersten Aufruf des Dialogs kein Wert in den Variablen für die Farbdarstellung vorhanden. Beim zweiten Aufruf läuft es dann wunderbar.

Viele Grüße,
Vanished

OpenOffice.info

Grafikeigenschaften eines Controls auslesen

Grafikeigenschaften eines Controls auslesen