Farben anpassen
Moderator: Moderatoren
Farben anpassen
Hallo,
ich hätte 2 Fragen zur farblichen Gestaltung eines Programms:
1. gibt es eine Möglichkeit, die Farben programmweit festzulegen?
Es ist nämlich sehr zeitaufwendig, in einem bestehenden Programm
jedes Objekt manuell zu verändern.
2. ist es möglich, die Farben der Scroll-Balken zu verändern?
Diese erscheinen immer in dem hässlichen Grau.
Ich arbeite sowohl mit xBase++ und eXpress++
Für Eure Hilfe besten Dank.
Günter
ich hätte 2 Fragen zur farblichen Gestaltung eines Programms:
1. gibt es eine Möglichkeit, die Farben programmweit festzulegen?
Es ist nämlich sehr zeitaufwendig, in einem bestehenden Programm
jedes Objekt manuell zu verändern.
2. ist es möglich, die Farben der Scroll-Balken zu verändern?
Diese erscheinen immer in dem hässlichen Grau.
Ich arbeite sowohl mit xBase++ und eXpress++
Für Eure Hilfe besten Dank.
Günter
- Jan
- Marvin
- Beiträge: 14651
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Hallo Günter,
zu Frage 2 zuerst, das geht am schnellsten: Meines Wissens nicht.
Zu frage 1: Ich mache das immer so, daß ich beim Programmstart einige Publics anlege mit den Farbwerten für verschiedene Aufgaben. Hintergrund Dialoge, Hintergrund Fenster, farbe Font, etc. Und diese Variablen setze ich dann in die entsprechenden Presentations Parameter ein. Und wenn mir was nicht mehr gefällt muß ich das nur 1 mal ganz am Anfang ändern, und alle Werte sind damit automatisch mit korrigiert.
Jan
zu Frage 2 zuerst, das geht am schnellsten: Meines Wissens nicht.
Zu frage 1: Ich mache das immer so, daß ich beim Programmstart einige Publics anlege mit den Farbwerten für verschiedene Aufgaben. Hintergrund Dialoge, Hintergrund Fenster, farbe Font, etc. Und diese Variablen setze ich dann in die entsprechenden Presentations Parameter ein. Und wenn mir was nicht mehr gefällt muß ich das nur 1 mal ganz am Anfang ändern, und alle Werte sind damit automatisch mit korrigiert.
Jan
Hallo Jan,
danke für Deine schnelle Antwort.
In meinen neueren Programmen mache ich das auch so, aber ich habe ein älteres Programm umgesetzt, und dort keine Presentation Parameter eingetragen. Es gab damals ja auch nur "hässlich Grau".
Wenn es keine andere Möglichkeit gibt, weiss ich wenigstens, was ich die nächsten Tage (und Nächte) zu tun habe.
Günter
danke für Deine schnelle Antwort.
In meinen neueren Programmen mache ich das auch so, aber ich habe ein älteres Programm umgesetzt, und dort keine Presentation Parameter eingetragen. Es gab damals ja auch nur "hässlich Grau".
Wenn es keine andere Möglichkeit gibt, weiss ich wenigstens, was ich die nächsten Tage (und Nächte) zu tun habe.
Günter
- Wolfgang Ciriack
- Der Entwickler von "Deep Thought"
- Beiträge: 2934
- Registriert: Sa, 24. Sep 2005 9:37
- Wohnort: Berlin
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Hallo JanJan hat geschrieben: Zu frage 1: Ich mache das immer so, daß ich beim Programmstart einige Publics anlege mit den Farbwerten für verschiedene Aufgaben.
ich hab gemeint, PUBLIC soll man in XBase nicht mehr verwenden?
Geht das auch mit STATIC?
Wolfgang,
könntest du mal kurz erklären, was eine Manifestdatei ist?
Ist das Teil von Windows?
Dann müsste man sich bei M$ schlau machen?
Da kann man aber keine eigenen Farben verwenden?
g
Daniel
- Jan
- Marvin
- Beiträge: 14651
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Daniel,
eine Manifestdatei musst Du Dir selber erstellen.
Sie heißt so wie Dein Progeamm, und zusätzlich die Endung .Manifest. Also insgesamt MeineAnwendung.exe.Manifest.
Der Inhalt der Datei ist fast komplett immer identisch:
Nur die Zeile " name="Company.Abteilung.Anwendungsname"
musst Du selber anpassen an Deine Gegebenheiten. Danach wird Deine Applikation unter XP die neue Optik haben. Man kann das ganze auch über ARC einbinden, dann brauch man nihct immer die Datei beizugeben.
Jan
eine Manifestdatei musst Du Dir selber erstellen.
Sie heißt so wie Dein Progeamm, und zusätzlich die Endung .Manifest. Also insgesamt MeineAnwendung.exe.Manifest.
Der Inhalt der Datei ist fast komplett immer identisch:
Code: Alles auswählen
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="5.0.0.0"
processorArchitecture="X86"
name="Company.Abteilung.Anwendungsname"
type="win32"
/>
<description>Your app description here</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>
musst Du selber anpassen an Deine Gegebenheiten. Danach wird Deine Applikation unter XP die neue Optik haben. Man kann das ganze auch über ARC einbinden, dann brauch man nihct immer die Datei beizugeben.
Jan
- brandelh
- Foren-Moderator
- Beiträge: 15695
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Hi,Daniel hat geschrieben:Jan hat geschrieben:ich hab gemeint, PUBLIC soll man in XBase nicht mehr verwenden?
Geht das auch mit STATIC?
in diesem Falle wäre es ja nur READONLY, also kein Problem.
STATIC ginge nur, wenn aller Code in einer PRG stünde, da maximal Dateiweit sichtbar (soweit ich weiß).
Gruß
Hubert
Hubert
- AUGE_OHR
- Marvin
- Beiträge: 12906
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 45 Mal
hi,
verwenden. Um meine damaligen S87 Module auf v5.x zu bringen
hatte ich ein Tool ("Summer´93" von QBS ) was mir aus jeder
PUBLIC Variable eine FUNCTION (PRG) machte.
aber wenn man es nach "Summer´93" Prinzip machst :
-> CFARBE1.PRG
somit hast du also ein Modul "cFarbe1" was deine PUBLIC Variable
"ersetzt".
gruss by OHR
Jimmy
Schon unter Cl*pper v5.x sollte man PUBLIC und PRIVAT "sparsam"Daniel hat geschrieben: ich hab gemeint, PUBLIC soll man in XBase nicht mehr verwenden?
verwenden. Um meine damaligen S87 Module auf v5.x zu bringen
hatte ich ein Tool ("Summer´93" von QBS ) was mir aus jeder
PUBLIC Variable eine FUNCTION (PRG) machte.
Um es "im gesamten Programm" zu verwenden gehen STATIC nicht,Daniel hat geschrieben: Geht das auch mit STATIC?
aber wenn man es nach "Summer´93" Prinzip machst :
Code: Alles auswählen
PUBLIC cFarbe1 := ....
Code: Alles auswählen
STATIC cFarbe1 := NIL
FUNCTION cFarbe1(value)
IF PCOUNT() > 0
cFarbe1 := value
ENDIF
RETURN cFarbe1
"ersetzt".
gruss by OHR
Jimmy
- brandelh
- Foren-Moderator
- Beiträge: 15695
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Hi,
wenn man im Programm nach dem ersten Initialisieren nur noch lesend darauf zugreift, sind PUBLIC Zugriffe auf jeden Fall schneller als Funktionsaufrufe und kein Problem. Ob dies aber überhaupt messbar ist hängt sehr vom Programm ab. In solchen habe ich z.B. meine Druckersteuerzeichen für die alte set printer to ... Druckroutinen abgelegt.
Für änderbare PUBLIC Variablen verwende ich solche Funktionen aber auch sehr gerne. Auch speichere ich kleinere Hilfsdateien in solchen Funktionen mit static arrays ab. Änderungen sind dann zwar erst beim Neustart sichtbar, aber ich erspare dem Programm viele Dateizugriffe, die im Netzwerk ganz schön langsam sein können.
wenn man im Programm nach dem ersten Initialisieren nur noch lesend darauf zugreift, sind PUBLIC Zugriffe auf jeden Fall schneller als Funktionsaufrufe und kein Problem. Ob dies aber überhaupt messbar ist hängt sehr vom Programm ab. In solchen habe ich z.B. meine Druckersteuerzeichen für die alte set printer to ... Druckroutinen abgelegt.
Für änderbare PUBLIC Variablen verwende ich solche Funktionen aber auch sehr gerne. Auch speichere ich kleinere Hilfsdateien in solchen Funktionen mit static arrays ab. Änderungen sind dann zwar erst beim Neustart sichtbar, aber ich erspare dem Programm viele Dateizugriffe, die im Netzwerk ganz schön langsam sein können.
Gruß
Hubert
Hubert
Hallo Jimmy und Hubert
das sind sehr nützliche Tipps aus der Praxis!
herzlichen Dank.
Und wie wäre es mit Einträgen in eine INI-Datei, die jedes Modul selber abfragt?
Dann erhielte man eine optimale Kapselung, resp. Unabhängigkeit der Module, die wir ja in der OOP anstreben.
Oder ist das zu aufwändig?
Gruss
Daniel
das sind sehr nützliche Tipps aus der Praxis!
herzlichen Dank.
Und wie wäre es mit Einträgen in eine INI-Datei, die jedes Modul selber abfragt?
Dann erhielte man eine optimale Kapselung, resp. Unabhängigkeit der Module, die wir ja in der OOP anstreben.
Oder ist das zu aufwändig?
Gruss
Daniel
- brandelh
- Foren-Moderator
- Beiträge: 15695
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Hi,
wenn ich den Zustand einer Variablen über die Laufzeit hinaus speichern möchte oder für Hilfstabellen könnte man auch INI Dateien verwenden. Diese ziehe ich wegen der leichten Bedienbarkeit der registry auf jeden Fall vor, aber ob ich alle Module so steuern würde, das hängt sehr vom Einsatzzweck und dem Programmierstil zusammen.
Wenn man nur wenige Male z.B. beim Fensteröffnen auf kleine externe Dateien zugreift, dürfte das kein Problem sein, im Browser Zelle für Zelle wahrscheinlich schon ... viele Wege führen nach Rom - weniges ist wirklich falsch, meistens handelt es sich nur um persönliche Vorlieben.
Bei den heutigen Rechnern (CPU, Cache, Festplatten etc.) ist vieles möglich, was vor 10 Jahren unter Clipper in eine Warteorgie verfallen wäre.
wenn ich den Zustand einer Variablen über die Laufzeit hinaus speichern möchte oder für Hilfstabellen könnte man auch INI Dateien verwenden. Diese ziehe ich wegen der leichten Bedienbarkeit der registry auf jeden Fall vor, aber ob ich alle Module so steuern würde, das hängt sehr vom Einsatzzweck und dem Programmierstil zusammen.
Wenn man nur wenige Male z.B. beim Fensteröffnen auf kleine externe Dateien zugreift, dürfte das kein Problem sein, im Browser Zelle für Zelle wahrscheinlich schon ... viele Wege führen nach Rom - weniges ist wirklich falsch, meistens handelt es sich nur um persönliche Vorlieben.
Bei den heutigen Rechnern (CPU, Cache, Festplatten etc.) ist vieles möglich, was vor 10 Jahren unter Clipper in eine Warteorgie verfallen wäre.
Gruß
Hubert
Hubert