Wunsch-Controls

[UliTs]

Mein größter Wunsch ist ein schnelles, sauberes XbpBrowse mit weiter oben genannten zusätzlichen Eigenschaften/Möglichkeiten. Das bedeutet meiner Meinung, daß XbpBrowse komplett neu geschrieben werden muß (der zugehörige Quellcode ist chaotisch und meines Erachtens nicht wartbar).

Jan: Wenn Du alles zusammenfaßt (bestimmt sehr viel Arbeit), veröffentliche am Besten das Ergebnis hier (oder mit Link in einer neuen Nachricht). Dann könnte man auch über die Priorität der einzelnen Punkte diskutieren.

Uli

[Jan]

Hallo Uli,

Danke für die Vorschußlorbeeren, aber das hier ist Andreas Thread. Der wurde als VIP der XUG Osnabrück anlässlich unseres XUG-Treffens vergangene Woche darum gebeten. Und so wird er sich um alles Weitere kümmern, wie Prioritäten und Weiterleiten an Steffen.

Jan

[UliTs]

Oh, sorry Andreas.

Uli

[michael32710]

Solange "Xbase++ registry class" und "Taskbar Library for Xbase++" noch nicht in der XppSys.dll zu finden sind :
http://www.software-braun.de/
MfG
Michael

[AUGE_OHR]

moin,

ich wünsche mit ein "funktionsfähiges" CreateObject() und ein "kompatibles" XbpActiveXControl() dazu ( oder ganz "weg" ... )
Grund : siehe dazu http://www.xbaseforum.de/viewtopic.php?f=28&t=4454

[andreas]

Hallo,

ich habe die Liste zusammengestellt und hänge meine Word-Datei diesem Beitrag an.

Folgend ist findet ihr die Wunschliste, für die wir eine Priorität legen sollten:

• Unicode / DBCS fähige Controls.
• XBPBrowse
• XbpGridControl
• Listboxen
• ListView
• XBPStatic
• XbpRibbonBar
• XbpSlider
• XbpTrayItem
• Eigenschaft :tooltipText
• "neue" Win-API Controls mit 3D Hardware Unterstützung e.g. MFC/MFP
• ActiveX
• XppFD - "Menu"
• GRA-Engine
• QuickBrowse
• INI-Datei-Klasse
• RegClass
• .NET
• Grabackground()
• Ownerdraw Menu mit SkinFramework
• GDI32
• ein "funktionsfähiges" CreateObject() und ein "kompatibles" XbpActiveXControl()

[andreas]

Die Reihenfolge in der oberen Liste ist in den meisten Fällen so einbehalten, wie die Wünsche rein gekommen sind. Ein Paar davon habe ich aber verschoben.

[andreas]

Wird es hier noch über die Prioritäten abgestimmt oder kann ich die Liste so absenden?

[Jan]

Also ich persönlich finde die Reihenfolge ganz OK. Du hast allerdings die ganzen Nicht-XBParts-Sachen dringelassen. Das finde ich nicht grundsätzlich falsch, ich weiß ja nicht, wie eng Steffen das sieht. Ansonsten wäre das vielleicht was für eine kommende Aufstellung über ein anderes Thema.

In der bestehenden Aufstellung würde ich das Rendering der GRA-Teile weiter nach oben schieben, weil das relativ weitreichende Folgen hätte, die vielen Parts zugutekommen würden.

Achso: Beim ersten Lesens schon hat mich gestört, das alles in Ich-Form geschrieben ist. Das solltest Du vielleicht neutral umschreiben.

Jan

[AUGE_OHR]

hi,

ich finde es nicht in der Liste : XBPSYSCLR_TRANSPARENT für alle XbParts !!! aus wenn "nicht" OS() "konform".

bei vielen XbParts kann man zwar XBPSYSCLR_TRANSPARENT als Hintergrund setzten, aber man bekommt nur "schwarz" oder "weiss".

bei "weiss" ist es wohl der "visual Style" der noch "hinter" dem Hintergrund liegt.
bei "schwarz" ... hm

Ist die Systemfarbe "transparent" (XBPSYSCLR_TRANSPARENT) als Hintergrundfarbe definiert, verwendet GraBackground() Grafikinformationen aus dem Ausgabebereich des Parent-Objekts des Xbase Parts zum Zeichnen des Hintergrunds.

funktioniert es wohl nicht "richtig".

"Win" XbParts : damit meine ich jetzt SLE, MLE, Listbox, Combobox etc.
... wenn ich mir die Codejock Control oder MsComCtl ansehe finde ich dort überall ein Property "transparency" was funktioniert.

"pure" XbParts wie XbpBrowse

"Gra" XbParts : auch mit Gra Function geht mit

Code: Alles auswählen

aAttr [ GRA_AS_BACKCOLOR ] := XBPSYSCLR_TRANSPARENT

und Matrix Operationen wie GraRotate nicht

"Aufklärung" über "Hintergrund"

Code: Alles auswählen

  GRA_AS_MIXMODE      GRA_FGMIX_*         GRA_FGMIX_OVERPAINT         
  GRA_AS_BGMIXMODE    GRA_BGMIX_*         GRA_BGMIX_LEAVEALONE         

// Vordergrund
   aAttr [ GRA_AS_MIXMODE   ] := GRA_FGMIX_OVERPAINT
*  aAttr [ GRA_AS_MIXMODE   ] := GRA_FGMIX_LEAVEALONE

// Hintergrund
   aAttr [ GRA_AS_BGMIXMODE ] := GRA_BGMIX_OVERPAINT
*  aAttr [ GRA_AS_BGMIXMODE ] := GRA_BGMIX_LEAVEALONE

im Zusammenhang mit XBPSYSCLR_TRANSPARENT.
Es scheint das man es nicht benutzten kann wenn man es später "überschreiben" will.

mit

Code: Alles auswählen

aAttr [ GRA_AS_BGMIXMODE ] := GRA_BGMIX_OVERPAINT

wird der Vordergrund (Buchstaben) zwar "übermalt" (Overpaint),
aber mit XBPSYSCLR_TRANSPARENT bekomme ich dann "schwarz" als Hintergrund.

[AUGE_OHR]

hi,

ich habe mal mit DragDrop rumgespielt. alle XbParts sind zwar "drop-fähig" aber sie haben nicht alle ein "drag" (Slot)

wenn ich aber mir die activeX ansehe z.b. Codejock oder MsComCtl dann ist sowohl OLE-drop und OLE-drag vorhanden.
hier mal ein Listview Beispiel

Code: Alles auswählen

Beispiel nur für ccCFFiles getestet
#define EvOLECompleteDrag        "OLECompleteDrag"
#define EvOLEDragDrop            "OLEDragDrop"
#define EvOLEDragOver            "OLEDragOver"
#define EvOLEStartDrag           "OLEStartDrag"
...
   oListView:OLEDragMode   := ccOLEDragAutomatic
   oListView:OLEDropMode   := ccOLEDropManual
...
************************************************************************
*
* OLECompleteDrag  Occurs when a source component is dropped onto a target component,
* informing the source component that a drag action was either performed or canceled.
*
* OLEDragDrop      Occurs when a source component is dropped onto a target component when
* the source component determines that a drop can occur.
*
* OLEDragOver      Occurs when one component is dragged over another.
*
* OLEStartDrag     Occurs when a component's OLEDrag method is performed, or when a
* component initiates an OLE drag/drop operation when the OLEDragMode property is set to
* Automatic.
*
************************************************************************

   ::SubscribeEvent( EvDblClick    , {|a,b,c,d| ::_itemSelected(a,b,c,d)  })
   ::SubscribeEvent( EvColumnClick , {|a,b,c,d| ::_Sortitnow(a,b,c,d)     })

   ::SubscribeEvent( EvOLECompleteDrag, {|a            | ::_OLECompleteDrag(a)         })
   ::SubscribeEvent( EvOLEDragDrop    , {|a,b,c,d,e,f  | ::_OLEDragDrop(a,b,c,d,e,f)   })
   ::SubscribeEvent( EvOLEDragOver    , {|a,b,c,d,e,f,g| ::_OLEDragOver(a,b,c,d,e,f,g) })
   ::SubscribeEvent( EvOLEStartDrag   , {|a,b          | ::_OLEStartDrag(a,b)          })

RETURN self

METHOD XbpListView:_OLECompleteDrag(nEffect)
LOCAL cText  := ""

   cText += " Effekt :"+LTRIM(STR(nEffect))
   LogIt(cText) // Debug Logfile

RETURN self

METHOD XbpListView:_OLEDragDrop(oData,nEffect,nButton,nShift,nx,ny)
LOCAL cData    := ""
LOCAL cText    := ""
LOCAL nFormat  := 0
LOCAL oFiles
LOCAL i,iMax

   DO CASE
      CASE oData:GetFormat( ccCFText     )  ; cData := oData:GetData(ccCFText)
      CASE oData:GetFormat( ccCFBitmap   )  ; cData := "Bitmap"
      CASE oData:GetFormat( ccCFMetafile )  ; cData := "Metafile"
      CASE oData:GetFormat( ccCFDIB      )  ; cData := "DIB"
      CASE oData:GetFormat( ccCFPalette  )  ; cData := "Palette"
      CASE oData:GetFormat( ccCFEMetafile)  ; cData := "EMetafile"
      CASE oData:GetFormat( ccCFFiles    )
         oFiles := oData:Files
         iMax   := oFiles:Count
         FOR i:= 1 TO iMax
            cData += oFiles:Item(i)
         NEXT
      CASE oData:GetFormat( ccCFRTF      )  ; cData := "RTF"
   ENDCASE
   cText += cData

   cText += " Effekt :"+LTRIM(STR(nEffect))
   cText += " Button :"+LTRIM(STR(nButton))

   cText += " Shift :"
   IF NIL <> nShift
      cText += LTRIM(STR(nShift))
   ELSE
      cText += "???"
   ENDIF

   cText += " nx :"
   IF NIL <> nx
      cText += LTRIM(STR(nx))
   ELSE
      cText += "???"
   ENDIF

   cText += " ny :"
   IF NIL <> ny
      cText += +LTRIM(STR(ny))
   ELSE
      cText += "???"
   ENDIF

   LogIt(cText) // Debug Logfile

RETURN self

METHOD XbpListView:_OLEDragOver(oData,nEffect,nButton,nShift,nx,ny,nState )
LOCAL cData    := ""
LOCAL cText    := ""
LOCAL nFormat  := 0
LOCAL oFiles
LOCAL i,iMax

   DO CASE
      CASE oData:GetFormat( ccCFText     )  ; cData := oData:GetData(ccCFText)
      CASE oData:GetFormat( ccCFBitmap   )  ; cData := "Bitmap"
      CASE oData:GetFormat( ccCFMetafile )  ; cData := "Metafile"
      CASE oData:GetFormat( ccCFDIB      )  ; cData := "DIB"
      CASE oData:GetFormat( ccCFPalette  )  ; cData := "Palette"
      CASE oData:GetFormat( ccCFEMetafile)  ; cData := "EMetafile"
      CASE oData:GetFormat( ccCFFiles    )
         oFiles := oData:Files
         iMax   := oFiles:Count
         FOR i:= 1 TO iMax
            cData += oFiles:Item(i)
         NEXT
      CASE oData:GetFormat( ccCFRTF      )  ; cData := "RTF"
   ENDCASE
   cText += cData

   cText += " Effekt :"+LTRIM(STR(nEffect))
   cText += " Button :"+LTRIM(STR(nButton))

   cText += " Shift :"
   IF NIL <> nShift
      cText += LTRIM(STR(nShift))
   ELSE
      cText += "???"
   ENDIF

   cText += " nx :"
   IF NIL <> nx
      cText += LTRIM(STR(nx))
   ELSE
      cText += "???"
   ENDIF

   cText += " ny :"
   IF NIL <> ny
      cText += +LTRIM(STR(ny))
   ELSE
      cText += "???"
   ENDIF

   cText += " State :"
   IF NIL <> nState
      cText += LTRIM(STR(nState))
   ELSE
      cText += "???"
   ENDIF

   LogIt(cText) // Debug Logfile

RETURN self


METHOD XbpListView:_OLEStartDrag(oData, nEffect)
/***********************************************
ccOLEDropEffectNone 0
ccOLEDropEffectCopy 1
ccOLEDropEffectMove 2
ccOLEDropEffectScroll -2147483648
***********************************************/
LOCAL cData
LOCAL cText  := ""
LOCAL nCount := 0

   IF NIL <> oData
      nCount  := oData:Files:Count
      IF nCount > 0
         cData := oData:Files:Item(nCount)
         cText += cData
      ELSE
         cText += "oData ???"
      ENDIF
   ENDIF

   cText += " Effekt :"+LTRIM(STR(nEffect))
   LogIt(cText) // Debug Logfile

RETURN self

auch bei allen anderen Controls finde ich immer "beides" OLE-drag und OLE-drop und das möchte ich auch gerne für "alle" XbParts

[AUGE_OHR]

Wird es hier noch über die Prioritäten abgestimmt oder kann ich die Liste so absenden?

gibt es schon eine Antwort ...

[Manfred]

Nene,

bis Weihnachten ist es noch ein Weilchen.

[andreas]

Wir haben eine Anfrage über eine Wunschliste über die Xbase-Parts für die nächste XBPack bekommen und diese erstellt und an Alaska übergeben.
Meiner Meinung nach würde ich nicht mit einer Antwort rechnen, sondern abwarten, was in der nächsten XBPack-Version erscheint.
Aber um weitere gleiche Fragen zu vermeiden, werden ich eine Anfrage an Alaska senden und um eine Antwort bitten!

[andreas]

Ich habe wie versprochen, eine Anfrage an Steffen F. Pirsig gesendet und hier ist ein Ausschnitt davon:

... klaro gibt es ne Rueckmeldung. Leider werde ich aber hierzu
erst im September (2. Hälfte kommen). Habe ich dir aber
bereits in meiner dankes email-geschrieben. Wie bereits
ausgeführt haben wir die Liste kategorisiert, verteilt und
erst mal im Hause mit dem abgeglichen was da ist bzw. was
wir auch haben wollten, dann haben wir natürlich auch
einiges gelernt.

Leider habe ich die erwähnte Dankes-Email nicht bekommen. Diese ist wahrscheinlich durch den Spam-Filter nicht gekommen. Da muss ich demnächst besser aufpassen.

Laut der Antwort von Steffen geht die Verzögerung auf das Konto von Arctica.

... Nochmal, wir würden uns wünschen
wenn Ihr eine derartige Liste 1 mal im Jahr erstellen
würdet das wäre auf jeden Fall hilfreich für uns.

Das wäre evtl. die Aufgabe für den Verein, um das Sammeln der Vorschläge anzustossen und die Zusammenstellung an Alaska weiterzuleiten!!!

[Juergen]

.NET Unterstützung.

Ich bin froh, dass ich mich nicht auch noch mit diversen Frameworks von Microsoft
herumschlagen muß, welche das System nur weiter aufblähen.

Ich schätze Alaska Xbase++ als ein Komplettsystem, welches die kaufm. Programmierung
abdeckt, aber NUR in Verbindung mit Express++.

Ohne Express++ hätte ich mich niemals für Alaska Xbase++ entschieden, da die Portierung
zu aufwändig geworden wäre.

Ein integrierter Reportgenerator wäre allerdings nicht schlecht.

Außerdem glaube ich, dass eine Öffnung nach .NET das Ende von Xbase++ beschleunigen
würde.

Gruß
Jürgen

[brandelh]

Hi,

.NET ist eine zweischneidige Sache. Es muss möglich sein (ich habe aber nur darüber gelesen)
.NET Bibliotheken bzw. deren Funktionen aufzurufen. Dieses ist denke ich sehr wichtig.
Insbesondere dass es einfach und sauber geht.
Einen .NET kompaiblen Compiler (der also managed code erstellt) brauchen wohl die wenigsten.

[Tom]

Hallo, Jürgen.

Ein integrierter Reportgenerator wäre allerdings nicht schlecht.

Ein Reportgenerator, der vom Leistungsumfang den auf den Markt verfügbaren auch nur nahekommen würde, wäre eine Aufgabe für eine eigenständige zweite Firma ("Alaska Reports" ). Wenn man sich anschaut, was Tools wie List & Label, Chrystal Reports usw. leisten, ist die Neuentwicklung eines vergleichbaren Tools als Bestandteil eines exotischen Compilers schlicht wahnwitzig. Es gab vor Jahren mal ein Package aus Xbase++ und L&L, aber das ist wieder aus dem Angebot genommen worden. Jedenfalls gibt es kaum einen Drucktraum, den man sich nicht erfüllen kann, wenn man z.B. mit dieser Kombination arbeitet. Viele andere Entwicklungsumgebungen bieten auch nur vergleichsweise rudimentäre Reportfunktionen an, und die Entwickler, die damit arbeiten, setzen zusätzlich leistungsstarke Reportgeneratoren ein.

[Tom]

Hallo, Hubert.

Das sehe ich ähnlich - Zugriff sollte (sauber und einfach) möglich sein, aber .NET erzeugen, das braucht vermutlich niemand. Es geht lediglich um den logisch folgenden Schritt nach Active X.

[Koverhage]

Hallo,

es gab doch aber mal eine PDF von Alaska, in der so habe ich das in Erinnerung, darum ging
Komponenten von .NET zu verwenden

O-Ton Alaska++ (was ja bekanntermaßen nichts heißen soll)

With Xbase++ 1.9 you can use any .NET class

[Jan]

Das war die Research and Development, die Entwicklungstochter von Alaska. Die Seite wird seit Jahren nicht mehr gepflegt. Da waren .Net und Linux ganz hoch im Kurs, inkl. Planungspapiere, Strategien, etc.

Jan

[brandelh]

Hallo Klaus,

ich meine auch gelesen zu haben, dass jemand (in der Newsgroup) .NET Klassen aufrufen konnte,
aber grundsätzlich kann man mit c/c++ alles aufrufen, einfach und sicher muss es sein !
Vermutlich fehlen dazu aber wieder die richtigen Datentypen

[Koverhage]

Jan,

kann ich nicht beurteilen, bei mir steht Alaska-Software von 2006!!!!

dotnet-windows-vista-intro

Aber das Teil meine ich auch nicht, es gab eine PDF von Steffen, vielleicht finde ich das ja noch.

[Koverhage]

Wir können doch mit Xbase++ fast alles machen, sogar .NET
und das bereits seit 2002 !

Hier ist detailliert beschrieben wie es geht.

ftp://ftp.alaska-software.com/documents/dot_net.pdf