Farben anpassen

[gf210957]

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

[Jan]

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

[gf210957]

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

[Wolfgang Ciriack]

Wenn du die Scrollbalken und Buttons XP-like haben willst, erstell doch einfach eine Manifestdatei für deine exe. Wirkt dann natürlich nur unter XP mit aktiviertem XP-Design.

[Daniel]

Zu frage 1: Ich mache das immer so, daß ich beim Programmstart einige Publics anlege mit den Farbwerten für verschiedene Aufgaben.

Hallo Jan

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]

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:

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>

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

[brandelh]

ich hab gemeint, PUBLIC soll man in XBase nicht mehr verwenden?
Geht das auch mit STATIC?

Hi,

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ß).

[AUGE_OHR]

hi,

ich hab gemeint, PUBLIC soll man in XBase nicht mehr verwenden?

Schon unter Cl*pper v5.x sollte man PUBLIC und PRIVAT "sparsam"
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.

Geht das auch mit STATIC?

Um es "im gesamten Programm" zu verwenden gehen STATIC nicht,
aber wenn man es nach "Summer´93" Prinzip machst :

Code: Alles auswählen

PUBLIC cFarbe1 := ....

-> CFARBE1.PRG

Code: Alles auswählen

STATIC cFarbe1 := NIL
FUNCTION cFarbe1(value)
IF PCOUNT() > 0
    cFarbe1 := value
ENDIF
RETURN cFarbe1

somit hast du also ein Modul "cFarbe1" was deine PUBLIC Variable
"ersetzt".

gruss by OHR
Jimmy

[brandelh]

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.

[Daniel]

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

[brandelh]

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.