XbpParts.prg

[olaf870]

Hallo,
der Versuch die Klasse
CLASS XbpPushButton FROM XbpBasePushButton
durch einbindung von XbpParts.prg zu redefinieren, führt zu einem Fehler beim Linken. Die Fehlermeldung sagt, die Klasse XbpPushButton sei schon definiert und der Linker weigert sich - jedenfalls mit den üblichen Schaltern - die App zusammenzulinken.

Aber wie nutzt man denn nun die Eigenschaft, dass die Standard-Xbp´s von den entsprechenden XbpBase-Klassen abgeleitet werden, für Redefinitionen, bzw Erweiterungen der Originalklasse? Was ich nicht möchte ist die Klasse umzubenennen, d.h. die redefinierte Klasse muß in jedem Fall so heißen wie die Original Xbase-Klasse.

Wenn dies nicht möglich Sein sollte, dann interessiert mich der Sinn und Zweck der Einführung einer zwischengeschalteten zusätzlichen XbpBase-Klasse in 331?

Gruß
Olaf870

[Tom]

Hallo, Olaf.

Und was geschieht, wenn Du die zwei Zeilen Klassendefinition für XbpPushButton aus XbpParts.PRG einfach auskommentierst? Ich meine, ich verstehe den Linker - es gibt zwei gleichlautende Klassendefinition, which one shall I take? Ansonsten, siehe Rogers Code: Gerade beim Einsatz von Drittbibliotheken halte ich es für gefährlich, eine Standardklasse zu überschreiben. Eleganter (aber sicher auch mühevoller) ist die Schaffung einer neuen Klasse OBXbpPushButton.

Edit: Verstehe ich richtig, Du versuchst, XbpParts.PRG zusätzlich zu linken? Meiner Meinung nach geschieht das ohnehin automatisch.

[brandelh]

Hallo Tom,

so wie ich Olaf verstehe, will er XbpParts.prg direkt einbinden um dort eigene Eigenschaften unterzubringen. Genauso wie man AppSys.PRG oder DBESys.PRG nutzt. Allerdings wird eine local definierte Funktion immer der aus der DLL Datei vorgezogen, ob dies auch bei Klassen ist, weiß ich nicht.

[olaf870]

Tom:

Gerade beim Einsatz von Drittbibliotheken halte ich es für gefährlich, eine Standardklasse zu überschreiben.

Aber darum geht es gerade: Damit auch Drittbibliotheken in den Genuß der neuen Klasse kommen, muß die Klasse gleich heißen.

XbpParts.obj ist in der Tat schon in einer Xbase-Standard-dll eingelinkt. Wenn nicht, dann wäre es einfacher.

Aber welchen Sinn hat XbpParts.prg, wenn man es nicht verwenden kann?

Gruß
Olaf870

[andreas]

Hallo Olaf,

ich denke, dass die Datei als Beispiel dem XBase beigelegt wurde, um uns zu zeigen, wie die XBParts programmiert sind und evtl. als Grundsatz für abgeleitete Klassen.

[olaf870]

Hallo Andreas,
ich kann da meist nicht viel Informatives oder Neues erkennen.
Auszug XbpParts.prg:

Code: Alles auswählen

//////////////////////////////////////////////////////////////////////
/// <summary>
///  <para>
///   Deklaration der Klasse "XbpCombobox"
///  </para>
/// </summary>
//////////////////////////////////////////////////////////////////////
CLASS XbpCombobox FROM XbpBaseCombobox
ENDCLASS


//////////////////////////////////////////////////////////////////////
/// <summary>
///  <para>
///   Deklaration der Klasse "XbpListBox"
///  </para>
/// </summary>
//////////////////////////////////////////////////////////////////////
CLASS XbpListBox FROM XbpBaseListBox
ENDCLASS

Wäre doch gut, wenn man seine alten Xbase-Programme durch Redefinition der Xbase-Klassen mal schnell und wirkungsvoll anpassen könnte?
Gruß Olaf870

[brandelh]

Hallo,

egal was jetzt geht, die Lage der PRG (SYS Verzeichnis), der recht dürftige Inhalt der Implementierungen (verweisen meist auf die Basisklasse) läst nur den Schluss zu, dass genau wie bei APPSYS und DBESYS ein Ersatz/ eine Änderung des Origialcodes in der DLL möglich sein soll.

Alles andere macht aus meiner Sicht keinen Sinn.

[AUGE_OHR]

hi,

Was ich nicht möchte ist die Klasse umzubenennen, d.h. die redefinierte
Klasse muß in jedem Fall so heißen wie die Original Xbase-Klasse.

wieso ? ein einfaches :

Code: Alles auswählen

#define XbpPushbutton  MyButton

in der STD.CH reicht doch aus um alle "XbpPushButton" auf "MyButton"
"umzuleiten"

Damit auch Drittbibliotheken in den Genuß der neuen Klasse kommen, muß die Klasse gleich heißen.

hm, tja ... darf man das ... (wenn der Pushbutton nicht mehr wie einer
aussieht ...)

gruss by OHR
Jimmy

[Markus Walter]

Hi,

ich kann den Ansatz von Olaf durchaus verstehen. Ich benutze Express und wollte schon immer mal bei Roger nachfragen, ob er nicht einen "Zwischenschritt" (eine Ableitung) zwischen seinen Klassen und den Originalklassen anbieten könnte:

Code: Alles auswählen

CLASS DCXbpCombobox FROM MyXbpCombobox
ENDCLASS

CLASS MyXbpCombobox FROM XbpCombobox
ENDCLASS

Dann könnte man in MyXbpCombobox die eigenen Anpassungen vornehmen. Genau das wäre jetzt über XbpParts.prg theoretisch möglich (solange es kein Problem gibt weil evtl. das original XbpParts.prg schon in die Express-DLL eingelinkt ist...).

Natürlich darf man keine Änderungen vornehmen, die das System des Third-Party-Anbieters stören...

[olaf870]

Markus,
*genau* das ist es, was ich versuchte (eben ohne Roger zu belästigen).
Gruß
Olaf870

[Markus Walter]

Hi Olaf,

vielleicht sollten wir Ihn doch belästigen...

[olaf870]

Markus,
lassen wir erstmal. Ich habe am Donnerstag Kontakt zu Alaska aufgenommen, damit die das mal grundsätzlich klären, was das mit XbpParts.prg überhaupt soll.

Ich warte noch auf response.

Schreib doch Du auch mal, dann geht das mit der Antwort ev. schneller.

Gruß
Olaf870

[olaf870]

Hallo Allerseits,
Andreas von Alaska hat geantwortet. Bei ihm geht es. Und bei mir jetzt auch. Anscheindend lag es am Linker: Er kommt manchmal mit alten DEF und/oder EXP-Dateien nicht zurecht, bzw. baut sie nicht neu.

Also:
Xbpparts.PRG verändern und einlinken, dann DEF und EXP-Dateien löschen.

Für Markus und andere DC-Anwender: Xbparts.OBJ auch in DCLIPX.XPJ einlinken, dann geht z.B. folgendes:

Xbparts.prg:

Code: Alles auswählen

#include "font.ch"
#include "common.ch"
#include "gra.ch"

CLASS XbpPushButton FROM XbpBasePushButton
  EXPORTED:
    INLINE METHOD SetCaptionClr(cCaption, nClr, cFont)
      LOCAL oBmp, oPS, aBox, oFont, xSize, ySize, xPos, yPos

      DEFAULT cFont TO FONT_TIMES_MEDIUM
      DEFAULT lAlign TO .F.
      DEFAULT nClr TO GRA_CLR_CYAN

      oPS  := ::LockPS()
      oBmp := XbpBitmap():New(oPS):Create()
      aBox := GraQueryTextBox(oPS, cCaption)
      oBmp:Make(::Currentsize()[1], ::Currentsize()[2])
      oBmp:PresSpace(oPS)
      GraSetColor(oPS, nClr)
      xSize := aBox[4, 1] - aBox[2, 1]
      ySize := aBox[3, 2] - aBox[2, 2]
      xPos := (::currentSize()[1] - xSize) / 2
      yPos := (::currentSize()[2] - ySize) / 2
      oFont := XbpFont():new(oPs)
      oFont:create(cFont)
      GraSetFont(oPs, oFont)
      GraStringAt(oPS, {xPos, yPos}, cCaption)
      oBmp:PresSpace( )
      ::UnlockPS()
      oBmp:transparentClr := oBmp:GetDefaultBgColor()
      ::Caption := oBmp
      ::Configure()
   RETURN self
ENDCLASS

test.prg

Code: Alles auswählen

PROC TEST
LOCAL oPushBlue6W, oPushRed2W
         @ 7, 45  DCPUSHBUTTON CAPTION '+6W' ;
            SIZE 4, 1.2 ;
            OBJECT oPushBlue6W;
            TOOLTIP 'Wiedervorlage in 42 Tagen' ;
            FANCY ;
            ACTION { || NIL} ;

        @ 7, 49 + DCPUSHBUTTON CAPTION '+2W' ;      //
            SIZE 4, 1.2 ;
            OBJECT oPushRed2W;
            TOOLTIP 'Wiedervorlage in 2 Wochen' ;
            FANCY ;
            ACTION { || NIL } ;


        DCREAD GUI ;
                EVAL { | o | ;
                            , oPushBlue6W:SetCaptionClr( "Hal" ), GRA_CLR_BLUE );
                            , oPushRed2W:SetCaptionClr( "lo" ), GRA_CLR_RED, );
                            };

RETURN

Also: XbpParts ist doch nicht so nutz- und sinnlos. So hat man nun also doch die Möglichkeit, das ein bischen statisch daherkommende (aber recht gute) DC-System etwas aufzustylen. Andreas rät zwar davon ab, da was zu ändern. Aber gegen so ein paar winzige Kleinigkeiten ist sicher nichts einzuwenden.
Gruß
Olaf870

[Markus Walter]

danke für die Nachricht, werde es mal versuchen, wenn ich nochmal Bedarf an so was habe... (zur Zeit habe ich zu viel zu tun...)