Grafikeigenschaften eines Controls auslesen
Moderator: Moderatoren
Grafikeigenschaften eines Controls auslesen
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
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
Hallo Vanished,
Ich verstehe Dein Problem, nämlich das z.B. ein solcher Code:
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
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
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
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: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).
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.dass unabhängig von den persönlichen Farbeinstellungen des Benutzers ein "schön" aussehender Dialog angezeigt wird.
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
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
Das funktioniert bei mir ganz problemlos mit folgendem Code: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.
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
Gruß
Stephan
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
heissen.
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)
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.
Nö,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.
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
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:
ist die Tatsache das alles eimal Feldvariable und einmal 'normale' Variable ist, denn schon diese Kontruktion funktioniert nicht:
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?
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
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)
Code: Alles auswählen
option explicit
Sub Main
Dim alles
Dim alles(28)
End Sub
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?
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.Nach der Änderung steht in jeder Variable der zutreffende Wert.
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
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:
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
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
....
Naja, vielleicht hilft es.
Schöne Grüße
Thomas
Unterstützer LibreOffice, zertifizierter Trainer und Berater
Bücher: LibreOffice 6- Einstieg und Umstieg
Makros Grundlagen - LibreOffice / OpenOffice Basic
Bücher: LibreOffice 6- Einstieg und Umstieg
Makros Grundlagen - LibreOffice / OpenOffice Basic
Deine Schlußfolgerung ist 100% richtig.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?
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
Hallo Thomas,
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.
Keine Frage man soll sich an das erste "Programmierergebot" halten ("Du sollst Option explicit verwenden"), also man sollte immer deklarieren.
@Vanished
Ja, dafür ist das Forum da und ich diskutiere gerne etwas verzwickte SAchen, da ich dadurch lerne.
Gruß
Stephan
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.
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.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.
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
Hallo Stephan,
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
Nein. Ich nehme sogar an, dass es sich um einen Bug handelt....Ich nehme jedoch an das Du einen Grund für dieses Verhalten auch nicht kennst.
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
Unterstützer LibreOffice, zertifizierter Trainer und Berater
Bücher: LibreOffice 6- Einstieg und Umstieg
Makros Grundlagen - LibreOffice / OpenOffice Basic
Bücher: LibreOffice 6- Einstieg und Umstieg
Makros Grundlagen - LibreOffice / OpenOffice Basic
nachdem ich es überschlafen habe versuche ich mal eine andere zu geben:Das zumindest wäre eine Erklärung.
In der Blibliothek "ImportWizard" gibt es im Modul "API" diese Deklaration:
Code: Alles auswählen
Public Const HKEY_CURRENT_USER = &H80000001
Damit das Makro mit einmaligem Aufruf funktioniert reicht es:
Code: Alles auswählen
farbe = QueryValue(HKEY_CURRENT_USER, "Control Panel\Colors",wert(i))
Code: Alles auswählen
farbe = QueryValue(&H80000001, "Control Panel\Colors",wert(i))
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
Edit: upppps, letzten Beitrag von Thomas übersehen... Insofern erübrigt sich der Rest meines Textes eigentlich. Jetzt funktioniert alles prima.
Nochmals vielen Dank!
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
Nochmals vielen Dank!
Hallo ihr beiden,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
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