Wunsch-Controls
Moderator: Moderatoren
- andreas
- Der Entwickler von "Deep Thought"
- Beiträge: 1902
- Registriert: Mi, 28. Sep 2005 10:53
- Wohnort: Osnabrück
- Hat sich bedankt: 4 Mal
- Kontaktdaten:
Wunsch-Controls
Hallo an Alle!
Bei dem letzten Treffen von XUG Osnabrück haben wir über eine Frage von Steffen Pirsig diskutiert und haben uns entschieden, diese hier zu veröffentlichen, da diese für alle interessant ist. Damit sollten wir unserer Meinung nach mehr Informationen zusammen bekommen, die dann an Steffen weitergeleitet werden!
Frage
Wir sollen eine Liste der gewünschten Controls erstellen, die von den Entwicklern noch als Erweiterung für Xbase++ gewünscht sind. Diese Liste soll möglichst nach Priorität sortiert werden.
Die Liste wird an Alaska Software weitergeleitet und evtl. werden die gewünschten Controls in den nächsten XBPacks einfließen.
Ich würde sagen, dass jeder hier sein Vorschlag mit genauer Beschreibung dazu macht. Dann werde ich die Daten zusammenstellen und weitergeben.
Bei dem letzten Treffen von XUG Osnabrück haben wir über eine Frage von Steffen Pirsig diskutiert und haben uns entschieden, diese hier zu veröffentlichen, da diese für alle interessant ist. Damit sollten wir unserer Meinung nach mehr Informationen zusammen bekommen, die dann an Steffen weitergeleitet werden!
Frage
Wir sollen eine Liste der gewünschten Controls erstellen, die von den Entwicklern noch als Erweiterung für Xbase++ gewünscht sind. Diese Liste soll möglichst nach Priorität sortiert werden.
Die Liste wird an Alaska Software weitergeleitet und evtl. werden die gewünschten Controls in den nächsten XBPacks einfließen.
Ich würde sagen, dass jeder hier sein Vorschlag mit genauer Beschreibung dazu macht. Dann werde ich die Daten zusammenstellen und weitergeben.
- andreas
- Der Entwickler von "Deep Thought"
- Beiträge: 1902
- Registriert: Mi, 28. Sep 2005 10:53
- Wohnort: Osnabrück
- Hat sich bedankt: 4 Mal
- Kontaktdaten:
Re: Wunsch-Controls
Ich möchte hier auch schon eine Erweiterung vorschlagen:
XBPBrowse soll um folgende Eigenschaften erweitert werden:
- Mehrzeilige Texte für Kopf- und Fuß-Beschriftung so wie auch für die Datenzeilen.
- Gruppierung der Daten-Zeilen.
- Eine Möglichkeit, ohne großen Aufwand, die Daten direkt im Browse zu bearbeiten.
Dies alles sollte möglichst über Parameter einstellbar sein.
XBPBrowse soll um folgende Eigenschaften erweitert werden:
- Mehrzeilige Texte für Kopf- und Fuß-Beschriftung so wie auch für die Datenzeilen.
- Gruppierung der Daten-Zeilen.
- Eine Möglichkeit, ohne großen Aufwand, die Daten direkt im Browse zu bearbeiten.
Dies alles sollte möglichst über Parameter einstellbar sein.
- Jan
- Marvin
- Beiträge: 14641
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 87 Mal
- Kontaktdaten:
Re: Wunsch-Controls
Die vorhandenen XBPack-Parts in offizielle XBParts überführen (z. B: XbpProgressbar) bzw. die bestehenden XBParts entsprechend erweitern (z. B. XbpImageButton).
Jan
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Jan
- Marvin
- Beiträge: 14641
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 87 Mal
- Kontaktdaten:
Re: Wunsch-Controls
In Listboxen (und damit auch den Comboboxen) saubere Spalten erzeugen können.
Jan
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Rolf Ramacher
- Der Entwickler von "Deep Thought"
- Beiträge: 1930
- Registriert: Do, 09. Nov 2006 10:33
- Wohnort: Bergheim
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Wunsch-Controls
Hallo Andreas
bei Static_:
kann man ja farbig darstellen. Dabei wird aber nur der Text farbig dargestellt. Nicht aber die Umrandung der Groupbox.- das sollte geändert werden.
bei Static_:
Code: Alles auswählen
oStatic:type := XBPSTATIC_TYPE_GROUPBOX
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9345
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 100 Mal
- Danksagung erhalten: 359 Mal
- Kontaktdaten:
Re: Wunsch-Controls
Hallo, Andreas.
Im Prinzip müsste es eine neue Klasse "XbpGridControl" geben. Diese sollte erlauben:
- Nutzung von Markup Text in Zellen (damit wäre "mehrzeilig" hinfällig, weil das ein Seiteneffekt wäre)
- Datentypenwechsel innerhalb einer Spalte (!) - also Anzeige von Texten, Bitmaps usw. in derselben Spalte bzw. auch in derselben Zelle (ginge mit Unterstützung von Markup)
- Subgrids - Tabellen als "Töchter" von Tabellenzeilen (ein-/ausblendbar) mit unterschiedlichen Zellenbreiten und -höhen
- wechselnde Zeilenhöhen innerhalb eines Grids
- Optimierungsfunktionen: Spaltenbreiten orientieren sich an den Inhalten und/oder der Bildschirm-/Controlgröße
usw. Als Beispiel/Vorlage sollten die Grids dienen, die es in großer Vielzahl (leider nicht als AX-Controls) für andere Entwicklungsumgebungen gibt. Einen Ansatz liefert das "ReportControl" von Codejock, aber das ist leider unfassbar lahm und nicht sehr handlich.
Alternativ/zusätzlich wären wirklich aussagekräftige Beispiele zum Ownerdrawing bei XbpBrowses sehr hilfreich.
Außerdem wünsche ich mir sehr, dass XbpBrowses mit :UseVisualStyle := .T. unter Vista/Windows 7 (mit Aero-Theme oder ähnlichen) wechselnde Vordergrundfarben in nicht-markierten Zellen ermöglichen. Derzeit sind solche Zellen immer schwarz dargestellt, aber die Hintergrundfarbe kann wechseln.
Im Prinzip müsste es eine neue Klasse "XbpGridControl" geben. Diese sollte erlauben:
- Nutzung von Markup Text in Zellen (damit wäre "mehrzeilig" hinfällig, weil das ein Seiteneffekt wäre)
- Datentypenwechsel innerhalb einer Spalte (!) - also Anzeige von Texten, Bitmaps usw. in derselben Spalte bzw. auch in derselben Zelle (ginge mit Unterstützung von Markup)
- Subgrids - Tabellen als "Töchter" von Tabellenzeilen (ein-/ausblendbar) mit unterschiedlichen Zellenbreiten und -höhen
- wechselnde Zeilenhöhen innerhalb eines Grids
- Optimierungsfunktionen: Spaltenbreiten orientieren sich an den Inhalten und/oder der Bildschirm-/Controlgröße
usw. Als Beispiel/Vorlage sollten die Grids dienen, die es in großer Vielzahl (leider nicht als AX-Controls) für andere Entwicklungsumgebungen gibt. Einen Ansatz liefert das "ReportControl" von Codejock, aber das ist leider unfassbar lahm und nicht sehr handlich.
Alternativ/zusätzlich wären wirklich aussagekräftige Beispiele zum Ownerdrawing bei XbpBrowses sehr hilfreich.
Außerdem wünsche ich mir sehr, dass XbpBrowses mit :UseVisualStyle := .T. unter Vista/Windows 7 (mit Aero-Theme oder ähnlichen) wechselnde Vordergrundfarben in nicht-markierten Zellen ermöglichen. Derzeit sind solche Zellen immer schwarz dargestellt, aber die Hintergrundfarbe kann wechseln.
Herzlich,
Tom
Tom
-
- Rekursionen-Architekt
- Beiträge: 205
- Registriert: Mo, 07. Aug 2006 10:18
- Wohnort: Leipzig
- Danksagung erhalten: 11 Mal
Re: Wunsch-Controls
Hallo Andreas,
meine Wunsch-Controls (Xbase-Parts) sind:
- XbpRibbonBar
Multifunktionsleiste wie in Office 2007
- XbpSlider
Schieberegler
Gibt es bereits in der Prof.Subscription, aber dabei handelt es sich um ein "selbstgebasteltes",
auf XbpStatic basierendes Control. Hier ist das entsprechende Windows-Control gemeint.
- XbpTrayItem
Anzeigen und Steuern eines Symbols (Icons) im SysTray.
Die Controls sollten nicht ActiveX-basiert sein, um OCX-Control-Registrierungen zu vermeiden.
Ich habe noch einen weiteren Wunsch. Dabei handelt es sich zwar um kein Control, aber um
eine Eigenschaft, die alle von der Klasse XbpWindow abgeleiteten Controls (also fast alle
Xbase-Parts) besitzen: Die Eigenschaft bzw. die Instanzvariable :tooltipText, der eine als
Tooltip anzuzeigende Zeichenkette zugewiesen werden kann. Da diese Eigenschaft nun schon
seit der Version 1.9.331 existiert und auch in der Doku erwähnt wird, wäre es schön, wenn
sie auch funktional implementiert, sprich: die :tooltipText zugewiesene Zeichenkette
auch angezeigt würde.
Nebenbei: Ich halte das unter "...\Samples\Solutions" mitgelieferte Tooltip-Beispiel für eine
Kompromis-Lösung, die inzwischen sicherlich viele Xbase++-Programmierer (so auch ich) in
angepasster Form nutzen, die aber keine Dauerlösung für eine moderne Programmiersprache
sein sollte.
Meine eigene Tooltip-Lösung kann mehrzeilige Tooltips anzeigen. Es wäre sehr schön, wenn
Xbase++ dies in der nächsten Version auch könnte. Was mir noch gefallen würde, wäre
die Verwendung unterschiedlicher Schriftarten/Schriftformatierungen im Tootip-Text.
Danke und beste Grüße,
Sören
meine Wunsch-Controls (Xbase-Parts) sind:
- XbpRibbonBar
Multifunktionsleiste wie in Office 2007
- XbpSlider
Schieberegler
Gibt es bereits in der Prof.Subscription, aber dabei handelt es sich um ein "selbstgebasteltes",
auf XbpStatic basierendes Control. Hier ist das entsprechende Windows-Control gemeint.
- XbpTrayItem
Anzeigen und Steuern eines Symbols (Icons) im SysTray.
Die Controls sollten nicht ActiveX-basiert sein, um OCX-Control-Registrierungen zu vermeiden.
Ich habe noch einen weiteren Wunsch. Dabei handelt es sich zwar um kein Control, aber um
eine Eigenschaft, die alle von der Klasse XbpWindow abgeleiteten Controls (also fast alle
Xbase-Parts) besitzen: Die Eigenschaft bzw. die Instanzvariable :tooltipText, der eine als
Tooltip anzuzeigende Zeichenkette zugewiesen werden kann. Da diese Eigenschaft nun schon
seit der Version 1.9.331 existiert und auch in der Doku erwähnt wird, wäre es schön, wenn
sie auch funktional implementiert, sprich: die :tooltipText zugewiesene Zeichenkette
auch angezeigt würde.
Nebenbei: Ich halte das unter "...\Samples\Solutions" mitgelieferte Tooltip-Beispiel für eine
Kompromis-Lösung, die inzwischen sicherlich viele Xbase++-Programmierer (so auch ich) in
angepasster Form nutzen, die aber keine Dauerlösung für eine moderne Programmiersprache
sein sollte.
Meine eigene Tooltip-Lösung kann mehrzeilige Tooltips anzeigen. Es wäre sehr schön, wenn
Xbase++ dies in der nächsten Version auch könnte. Was mir noch gefallen würde, wäre
die Verwendung unterschiedlicher Schriftarten/Schriftformatierungen im Tootip-Text.
Danke und beste Grüße,
Sören
Zuletzt geändert von Sören am Di, 13. Jul 2010 15:16, insgesamt 1-mal geändert.
- Manfred
- Foren-Administrator
- Beiträge: 21165
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 206 Mal
- Danksagung erhalten: 67 Mal
Re: Wunsch-Controls
Hi Sören,
ich denke mit den Tooltips hast Du schlechte Karten. Ich meine mich erinnern zu können, das seit BalloonTip und CueBanner Steffen gesagt hatte, das die Tooltips out sind und nicht mehr eingebaut werden.
ich denke mit den Tooltips hast Du schlechte Karten. Ich meine mich erinnern zu können, das seit BalloonTip und CueBanner Steffen gesagt hatte, das die Tooltips out sind und nicht mehr eingebaut werden.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9345
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 100 Mal
- Danksagung erhalten: 359 Mal
- Kontaktdaten:
Re: Wunsch-Controls
Hallo, Manfred.
CueBanner und BalloonTips gibt es aber nur bei SLEs, MLEs und Comboboxen. Die iVar "Tooltiptext" kennt demgegenüber jedes von XbpIWindow abgeleitete Control. Ich zeige z.B. Tooltips bei Statics, die bei mir auch nicht selten (über den LbClick-Slot) gewisse Control-Funktionalitäten haben. Oder bei AX-Controls.
Allerdings. Es mag Gründe dafür geben, die Programmierung der Tooltip-Anzeige den Entwicklern überlassen zu haben. Wenn man mit diversen Threads arbeitet, kann das nämlich ganz schön haarig werden. Roger Donnay - den ich für einen der besten Xbase++-Programmierer auf diesem Planeten halte - hat sich jahrelang damit abgestrampelt, eine Lösung hierfür zu finden, die unter allen Bedinungen robust ist (und, z.B., auch mehrzeilige Anzeigen erlaubt).
CueBanner und BalloonTips gibt es aber nur bei SLEs, MLEs und Comboboxen. Die iVar "Tooltiptext" kennt demgegenüber jedes von XbpIWindow abgeleitete Control. Ich zeige z.B. Tooltips bei Statics, die bei mir auch nicht selten (über den LbClick-Slot) gewisse Control-Funktionalitäten haben. Oder bei AX-Controls.
Allerdings. Es mag Gründe dafür geben, die Programmierung der Tooltip-Anzeige den Entwicklern überlassen zu haben. Wenn man mit diversen Threads arbeitet, kann das nämlich ganz schön haarig werden. Roger Donnay - den ich für einen der besten Xbase++-Programmierer auf diesem Planeten halte - hat sich jahrelang damit abgestrampelt, eine Lösung hierfür zu finden, die unter allen Bedinungen robust ist (und, z.B., auch mehrzeilige Anzeigen erlaubt).
Herzlich,
Tom
Tom
-
- Rekursionen-Architekt
- Beiträge: 205
- Registriert: Mo, 07. Aug 2006 10:18
- Wohnort: Leipzig
- Danksagung erhalten: 11 Mal
Re: Wunsch-Controls
Hallo,
Im Übrigen können es andere Programmiersprachen ja auch. Xbase++ würde dadurch nur gewinnen.
Wenn er das wirklich gesagt hat, stellt sich mir die Frage, warum er seit Version 1.9 die iVar :tooltipText eingebaut und dokumentiert hat.Manfred hat geschrieben: Ich meine mich erinnern zu können, das seit BalloonTip und CueBanner Steffen gesagt hatte, das die Tooltips out sind und nicht mehr eingebaut werden.
Aber genau das ist der Grund, der sich hinter meinem "Wunsch" verbirgt. Mit der "festen" Implementierung der Tooltip-Funktionalität in Xbase++ muss doch eine bedeutend effektivere und stabilere Tooltip-Steuerung (auch mit Threads) möglich sein, als wenn sich jeder Programmierer selbst irgendwas zusammenschustert. Da schließe ich 3Party-Tools grundsätzlich mit ein.Tom hat geschrieben: Es mag Gründe dafür geben, die Programmierung der Tooltip-Anzeige den Entwicklern überlassen zu haben. Wenn man mit diversen Threads arbeitet, kann das nämlich ganz schön haarig werden.
Im Übrigen können es andere Programmiersprachen ja auch. Xbase++ würde dadurch nur gewinnen.
Beste Grüße,
Sören
Sören
- Manfred
- Foren-Administrator
- Beiträge: 21165
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 206 Mal
- Danksagung erhalten: 67 Mal
Re: Wunsch-Controls
Na gut, ok,
wenn Andreas die Wünsche usw. einreicht, dann wird Steffen sicherlich zu den Tooltips etwas sagen. Ich bin mir auch nicht mehr sicher, jedenfalls finde ich weder hier noch in meinen Mails etwas darüber.
wenn Andreas die Wünsche usw. einreicht, dann wird Steffen sicherlich zu den Tooltips etwas sagen. Ich bin mir auch nicht mehr sicher, jedenfalls finde ich weder hier noch in meinen Mails etwas darüber.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
- AUGE_OHR
- Marvin
- Beiträge: 12903
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 44 Mal
Re: Wunsch-Controls
hi,
grundsätzlich stimme ich den Wunsch zu, aber doch nicht die "alten" Controls welche Xbase++ noch verwendet.
Hierbei beziehe ich mich erstmal auf die Win-API Controls wo die "W" Functionen ja durch "A" Functionen in der SL1 "ausgetauscht" wurden.
1st Wunsch : "neue" Win-API Controls mit 3D Hardware Unterstützung e.g. MFC/MFP
Wir haben ja z.b. einen XbpPushbutton, aber es ist "nur" ein Button Style "normal".
Es gibt aber auch noch Style "DropDown","DropDownRight" und "SplitDropDown"
Naja Till hatte ja schon einen Fix für die BUGs in der Progressbar Class angekündigt ...
Die Aussage gilt für Xbase++ weil die activeX Schnittstelle "so langsam" (bis Faktor 40x !!! ) ist.
Wenn ich das ganze mit h... benutzen ist es so schnell als wenn ich Outlook dafür nehme.
2nd Wunsch : Überarbeitung der activeX Schnittstelle betreffend "Geschwindigkeit"
2a.) und wenn wir auch anderes als iDispatch benutzen könnten ...
Tom hat auch Markup mittels XML angesprochen. auch für Commandbars wird XML verwendet
3rd Wunsch : Markup und XML für XbParts
im übrigen sind die Ribbon nur ein Teil der Commandbars. Diese können per XML "beschrieben" werden und damit Menues erstellt werden.
4th Wunsch : XppFD Erweiterrung "Menu", wenn möglich per XML und Markup
aber auch die RegClass von Thomas Braun sollte in die XppSYS.DLL
ich gehe mal davon aus das mit der Wunschliste enthalte Controls in die Xbase++ LIB eingebunden werden und wir nur für Änderungen den Source zu XppSys benötigen.
***Manifest,Unicode/DBCS
so hier nun noch paar Wünsche von mir :
a.) Visual Style : XBPSYSCLR_TRANSPARENT führt oft nicht zum Ziel weil noch ein Visual Style "dazwischen" hängt.
b.) Grabackground() liefert nur "default" visual Style, nicht den aktiven "Skin" von FrameSkinwork
c.) Ownerdraw Menu mit SkinFramework
d.) Unicode / DBCS fähige Controls ... damit ich für chinesisch nicht mehr activeX verwenden muss
grundsätzlich stimme ich den Wunsch zu, aber doch nicht die "alten" Controls welche Xbase++ noch verwendet.
Hierbei beziehe ich mich erstmal auf die Win-API Controls wo die "W" Functionen ja durch "A" Functionen in der SL1 "ausgetauscht" wurden.
1st Wunsch : "neue" Win-API Controls mit 3D Hardware Unterstützung e.g. MFC/MFP
Wir haben ja z.b. einen XbpPushbutton, aber es ist "nur" ein Button Style "normal".
Es gibt aber auch noch Style "DropDown","DropDownRight" und "SplitDropDown"
XbpBrowse ist ja kein Win-API Control sondern "pure" Xbase++. Das sollte alles (Sourcecode) in die XppSys.DLLandreas hat geschrieben:XBPBrowse soll um folgende Eigenschaften erweitert werden:
- Mehrzeilige Texte für Kopf- und Fuß-Beschriftung so wie auch für die Datenzeilen.
- Gruppierung der Daten-Zeilen.
- Eine Möglichkeit, ohne großen Aufwand, die Daten direkt im Browse zu bearbeiten.
Dies alles sollte möglichst über Parameter einstellbar sein.
da es sich, wie bei den "Goodies" um Extras handelt, fürchte ich das es noch nicht mal Support dafür geben wird (s.h. DatePick "Bold" ).Jan hat geschrieben:Die vorhandenen XBPack-Parts in offizielle XBParts überführen (z. B: XbpProgressbar) bzw. die bestehenden XBParts entsprechend erweitern (z. B. XbpImageButton).
Naja Till hatte ja schon einen Fix für die BUGs in der Progressbar Class angekündigt ...
wobei wir auch ein ListView bräuchten !Jan hat geschrieben:In Listboxen (und damit auch den Comboboxen) saubere Spalten erzeugen können.
JaJaJa ... 100%Tom hat geschrieben:Im Prinzip müsste es eine neue Klasse "XbpGridControl" geben. Diese sollte erlauben:
@andreas "das" sind die Sachen die wir brauchen, nicht ein "aufgebohrtes" XbpBrowse was mit Ownerdraw quälend langsam ist.Tom hat geschrieben:- Nutzung von Markup Text in Zellen (damit wäre "mehrzeilig" hinfällig, weil das ein Seiteneffekt wäre)
- Datentypenwechsel innerhalb einer Spalte (!) - also Anzeige von Texten, Bitmaps usw. in derselben Spalte bzw. auch in derselben Zelle (ginge mit Unterstützung von Markup)
- Subgrids - Tabellen als "Töchter" von Tabellenzeilen (ein-/ausblendbar) mit unterschiedlichen Zellenbreiten und -höhen
- wechselnde Zeilenhöhen innerhalb eines Grids
- Optimierungsfunktionen: Spaltenbreiten orientieren sich an den Inhalten und/oder der Bildschirm-/Controlgröße
sorry aber das mit der Geschwindigkeit stimmt "so" nicht ganz.Tom hat geschrieben:Einen Ansatz liefert das "ReportControl" von Codejock, aber das ist leider unfassbar lahm und nicht sehr handlich.
Die Aussage gilt für Xbase++ weil die activeX Schnittstelle "so langsam" (bis Faktor 40x !!! ) ist.
Wenn ich das ganze mit h... benutzen ist es so schnell als wenn ich Outlook dafür nehme.
2nd Wunsch : Überarbeitung der activeX Schnittstelle betreffend "Geschwindigkeit"
2a.) und wenn wir auch anderes als iDispatch benutzen könnten ...
Tom hat auch Markup mittels XML angesprochen. auch für Commandbars wird XML verwendet
3rd Wunsch : Markup und XML für XbParts
Das wird NIE kommen, den dafür müsste Alaska ja eine Lizenz "kaufen" ...Sören hat geschrieben:- XbpRibbonBar
Multifunktionsleiste wie in Office 2007
im übrigen sind die Ribbon nur ein Teil der Commandbars. Diese können per XML "beschrieben" werden und damit Menues erstellt werden.
4th Wunsch : XppFD Erweiterrung "Menu", wenn möglich per XML und Markup
hm ... ja ... fehlt, aber das hat man doch selbst in < 5min gemacht mit MsComCTL.OCXSören hat geschrieben:- XbpSlider
Schieberegler
Gibt es bereits in der Prof.Subscription, aber dabei handelt es sich um ein "selbstgebasteltes",
auf XbpStatic basierendes Control. Hier ist das entsprechende Windows-Control gemeint.
gibt es von Thomas Braun TrayIcon Class.Sören hat geschrieben:- XbpTrayItem
Anzeigen und Steuern eines Symbols (Icons) im SysTray.
aber auch die RegClass von Thomas Braun sollte in die XppSYS.DLL
Die OCX Version ist "für uns" als "Wrapper" der entsprechenden API. Klar kannst du auch per DLL und BAP arbeiten wenn du willst.Sören hat geschrieben:Die Controls sollten nicht ActiveX-basiert sein, um OCX-Control-Registrierungen zu vermeiden.
ich gehe mal davon aus das mit der Wunschliste enthalte Controls in die Xbase++ LIB eingebunden werden und wir nur für Änderungen den Source zu XppSys benötigen.
da war doch was ... BalloonTip haben viele abgestellt ... CueBanner funktioniert nicht wenn*** ... und Tooltips sollten nicht aus einer DBF kommenTooltips hast Du schlechte Karten. Ich meine mich erinnern zu können, das seit BalloonTip und CueBanner
***Manifest,Unicode/DBCS
so hier nun noch paar Wünsche von mir :
a.) Visual Style : XBPSYSCLR_TRANSPARENT führt oft nicht zum Ziel weil noch ein Visual Style "dazwischen" hängt.
b.) Grabackground() liefert nur "default" visual Style, nicht den aktiven "Skin" von FrameSkinwork
c.) Ownerdraw Menu mit SkinFramework
d.) Unicode / DBCS fähige Controls ... damit ich für chinesisch nicht mehr activeX verwenden muss
gruss by OHR
Jimmy
Jimmy
- Jan
- Marvin
- Beiträge: 14641
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 87 Mal
- Kontaktdaten:
Re: Wunsch-Controls
Sorry, aber das ist Blödsinn. Gerade das macht ja so viele Probleme. Von MS nicht mehr supported, lahm + wie mein Ende vom Rückgrat + "ig", Probleme bei Installationen unter Vista/7. Sören hat weiter unten Recht: Bitte bei XBParts weg von ActiveX!AUGE_OHR hat geschrieben:hm ... ja ... fehlt, aber das hat man doch selbst in < 5min gemacht mit MsComCTL.OCXSören hat geschrieben:- XbpSlider
Schieberegler
Gibt es bereits in der Prof.Subscription, aber dabei handelt es sich um ein "selbstgebasteltes",
auf XbpStatic basierendes Control. Hier ist das entsprechende Windows-Control gemeint.
Und? Wo ist da das Problem? Warum soll mann denn da nicht eine Xbase++-interne Funktion draus machen? Die dann jedem user ohne Sucherei und Download zur Verfügung steht?AUGE_OHR hat geschrieben:gibt es von Thomas Braun TrayIcon Class.Sören hat geschrieben:- XbpTrayItem
Anzeigen und Steuern eines Symbols (Icons) im SysTray.
aber auch die RegClass von Thomas Braun sollte in die XppSYS.DLL
???AUGE_OHR hat geschrieben:Die OCX Version ist "für uns" als "Wrapper" der entsprechenden API. Klar kannst du auch per DLL und BAP arbeiten wenn du willst.Sören hat geschrieben:Die Controls sollten nicht ActiveX-basiert sein, um OCX-Control-Registrierungen zu vermeiden.
Volle Zustimmung!!!AUGE_OHR hat geschrieben: d.) Unicode / DBCS fähige Controls ... damit ich für chinesisch nicht mehr activeX verwenden muss
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9345
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 100 Mal
- Danksagung erhalten: 359 Mal
- Kontaktdaten:
Re: Wunsch-Controls
Zusatz: Ich wünsche mir außerdem ein vernünftiges Rendering in der GRA-Engine.
Herzlich,
Tom
Tom
- andreas
- Der Entwickler von "Deep Thought"
- Beiträge: 1902
- Registriert: Mi, 28. Sep 2005 10:53
- Wohnort: Osnabrück
- Hat sich bedankt: 4 Mal
- Kontaktdaten:
Re: Wunsch-Controls
Sind das jetzt alle Wünsche? Kann ich jetzt die Zusammenstellung machen oder kommt noch was?
- brandelh
- Foren-Moderator
- Beiträge: 15688
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Wunsch-Controls
Hatten wir den ListView schon, der z.B. vom Explorer bekannt ist.
Dann wäre es schön, wenn man bei QuickBrowse() automatisch per Maus die Spaltenbreite ändern könnte und
die Sortierung einer Spalte ohne eine Quellcodeorgie möglich wäre.
Damit meine ich jetzt nicht dass die Sortierung als solche erledigt wird, sondern dass die Anzeige und die callbacks
automatisch funktionieren, der Wechsel des Index bzw. des Arrays ist dann ja einfach.
Dann wäre es schön, wenn man bei QuickBrowse() automatisch per Maus die Spaltenbreite ändern könnte und
die Sortierung einer Spalte ohne eine Quellcodeorgie möglich wäre.
Damit meine ich jetzt nicht dass die Sortierung als solche erledigt wird, sondern dass die Anzeige und die callbacks
automatisch funktionieren, der Wechsel des Index bzw. des Arrays ist dann ja einfach.
Gruß
Hubert
Hubert
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9345
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 100 Mal
- Danksagung erhalten: 359 Mal
- Kontaktdaten:
Re: Wunsch-Controls
Hallo, Andreas.
Will sagen: Besserer (schnellerer!) Active-X-Support und die Fähigkeit, sicher und komfortabel auf .NET-Bibliotheken zuzugreifen - das wäre ein Wunsch, der sofort alle meine anderen Wünsche beseitigen würde.
Na ja. Wenn ich mir wirklich etwas wünschen dürfte, dann hätte ich gerne die Möglichkeit, auf alle Windows-Klassenbibliotheken zuzugreifen, die es so gibt, und zwar nicht vonhintendurchdiebrustinsauge. Es gibt großartige Grids da draußen, aber zumeist leider nur für .NET. Ich erwarte von Alaska auch nicht, dass sie mir einen konkurrenzfähigen Reportgenerator liefern, weil es mit Tools wie List & Label (das ich wirklich problemlos einbinden kann) Lösungen hierfür gibt, die auch mit Xbase++ verwendbar sind. Ich habe - im Gegensatz zu manch anderem hier - auch nichts dagegen, Active-X-Controls zu benutzen. Anwendungen in der Systray platzieren kann ich mit einer Komponente von Codejock, die ich sowieso besitze, weil ich die Xtreme Suite Pro habe - und ausliefere. Damit weiß ich wenigstens bei jedem Kunden sicher, was zur Verfügung steht und was nicht, und alle Controls aus der Bibliothek werden beim Programmstart auf Existenz geprüft und ggf. nachinstalliert. Leider aber hakelt das hier und da noch ein bisschen, und vor allem werden aufwendigere Controls (Calendar, ReportControl) unter Xbase++ sehr langsam.Sind das jetzt alle Wünsche?
Will sagen: Besserer (schnellerer!) Active-X-Support und die Fähigkeit, sicher und komfortabel auf .NET-Bibliotheken zuzugreifen - das wäre ein Wunsch, der sofort alle meine anderen Wünsche beseitigen würde.
Herzlich,
Tom
Tom
- Jan
- Marvin
- Beiträge: 14641
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 87 Mal
- Kontaktdaten:
Re: Wunsch-Controls
Hallo Tom,
falls Du auf meine diesbezügliche Kommentare anspielst: Ich habe nicht grundsätzlich etwas gegen ActiveX. Ich habe schon einige davon eingesetzt. Ich habe aber zwei Probleme da mit:
1) Wie Du selber sagst: Die Geschwindigkeit ist atemberaubend (lahm). Ich habe z. B. vergangene Woche meine Progressbar auf den neuen XBPack2-Progressbar umgebaut. Vorher habe ich das über eine selbstgestrickte Funktion mit MsComCtl gemacht, was ansich einwandfrei lief. Und was soll ich sagen: Die Geschwindigkeit des grafischen Aufbaus der Progressbar ist atemberaubend schneller. Was gerade bei der Progressbar sehr wichtig ist, da die immerhin recht häufig aktualisiert wird.
2) Ich habe massive Probleme mit ActiveX-Elementen unter Vista und 7. Ich habe meine Installationsroutine mit Inno erstellt. Null Probleme. Solange nicht ActiveX und Vista bzw. 7 im Spiel sind. Das leidige Rechte-Problem halt. Ein weiterer Grund, warum ich die Progressbar und RMChart von ActiveX weg umgeschrieben habe (bei RMChart sei hier insbesondere die massive Arbeit von Hubert erwähnt, die mir das erst möglich gemacht hat)
Von daher muß ich gestehen ist es mir lieber, wenn zumindest die XBParts nicht über ActiveX laufen würden. Und klar, da stimme ich Dir und anderen zu, wenn zusätzlich für die Fälle, wo sich ActiveX nicht umgehen lässt, die Schnittstelle wesentlich beschleunigt würde.
Außerdem habe ich mir sagen lassen (korrigiert mich, wenn ich da falsche liege), daß ActiveX auf dem absteigenden Ast ist und im Zuge der .Net-Umorientierung von MS auslaufen soll. Warum also sollet Alaska seine Xbase-Bestandteile in einer auslaufenden Technik aufbauen?
Jan
falls Du auf meine diesbezügliche Kommentare anspielst: Ich habe nicht grundsätzlich etwas gegen ActiveX. Ich habe schon einige davon eingesetzt. Ich habe aber zwei Probleme da mit:
1) Wie Du selber sagst: Die Geschwindigkeit ist atemberaubend (lahm). Ich habe z. B. vergangene Woche meine Progressbar auf den neuen XBPack2-Progressbar umgebaut. Vorher habe ich das über eine selbstgestrickte Funktion mit MsComCtl gemacht, was ansich einwandfrei lief. Und was soll ich sagen: Die Geschwindigkeit des grafischen Aufbaus der Progressbar ist atemberaubend schneller. Was gerade bei der Progressbar sehr wichtig ist, da die immerhin recht häufig aktualisiert wird.
2) Ich habe massive Probleme mit ActiveX-Elementen unter Vista und 7. Ich habe meine Installationsroutine mit Inno erstellt. Null Probleme. Solange nicht ActiveX und Vista bzw. 7 im Spiel sind. Das leidige Rechte-Problem halt. Ein weiterer Grund, warum ich die Progressbar und RMChart von ActiveX weg umgeschrieben habe (bei RMChart sei hier insbesondere die massive Arbeit von Hubert erwähnt, die mir das erst möglich gemacht hat)
Von daher muß ich gestehen ist es mir lieber, wenn zumindest die XBParts nicht über ActiveX laufen würden. Und klar, da stimme ich Dir und anderen zu, wenn zusätzlich für die Fälle, wo sich ActiveX nicht umgehen lässt, die Schnittstelle wesentlich beschleunigt würde.
Außerdem habe ich mir sagen lassen (korrigiert mich, wenn ich da falsche liege), daß ActiveX auf dem absteigenden Ast ist und im Zuge der .Net-Umorientierung von MS auslaufen soll. Warum also sollet Alaska seine Xbase-Bestandteile in einer auslaufenden Technik aufbauen?
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9345
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 100 Mal
- Danksagung erhalten: 359 Mal
- Kontaktdaten:
Re: Wunsch-Controls
Hallo, Jan.
Es ging mir nicht um eine Glaubensschlacht. Übrigens wurde schon viel angekündigt (so sollte die DOS-Box bereits ab Windows 2000 eigentlich nicht mehr zur Verfügung stehen, aber sogar in Windows 7 ist sie noch verfügbar), aber die tatsächlichen Geschehnisse wichen nicht selten davon ab. Ich glaube, dass es Active X noch ziemlich lange geben wird, aber ich hätte auch kein Problem damit, auf .NET-Klassenbibliotheken umzusteigen. Davon abgesehen: Xbase++ unterstützt Active X erst seit Version 1.9, und die ist von 2006. Davor haben diejenigen von uns, die mit solchen Komponenten hantieren wollten, auf Philippe Monteils "JazzAge" zurückgegriffen.
Ich wollte darauf hinaus, dass ich eigentlich nicht unbedingt will, dass mir Alaska eine eierlegende Wollmilchsau liefert, die es erlaubt, auf alle Drittprodukte zu verzichten. Mal davon abgesehen, dass ihnen das auch kaum gelingen wird (alleine ein wirklich guter Reportgenerator benötigte ein größeres Entwicklerteam als Alaska derzeit insgesamt hat), gibt es einerseits alles, was man bräuchte, irgendwo da draußen - und andererseits zwängen eigene (in der Entwicklungsumgebung enthaltene) Komponenten auch immer dazu, sich auf bestimmte visuelle und funktionale Fähigkeiten zu beschränken. Deshalb wäre es mir grundsätzlich lieber, einfach die Möglichkeit zu haben, das zu integrieren, was der Markt ohnehin anbietet. Und das robust und in angemessener Geschwindigkeit. Damit wären schon ziemlich viele Kühe vom Eis.
Es ging mir nicht um eine Glaubensschlacht. Übrigens wurde schon viel angekündigt (so sollte die DOS-Box bereits ab Windows 2000 eigentlich nicht mehr zur Verfügung stehen, aber sogar in Windows 7 ist sie noch verfügbar), aber die tatsächlichen Geschehnisse wichen nicht selten davon ab. Ich glaube, dass es Active X noch ziemlich lange geben wird, aber ich hätte auch kein Problem damit, auf .NET-Klassenbibliotheken umzusteigen. Davon abgesehen: Xbase++ unterstützt Active X erst seit Version 1.9, und die ist von 2006. Davor haben diejenigen von uns, die mit solchen Komponenten hantieren wollten, auf Philippe Monteils "JazzAge" zurückgegriffen.
Ich wollte darauf hinaus, dass ich eigentlich nicht unbedingt will, dass mir Alaska eine eierlegende Wollmilchsau liefert, die es erlaubt, auf alle Drittprodukte zu verzichten. Mal davon abgesehen, dass ihnen das auch kaum gelingen wird (alleine ein wirklich guter Reportgenerator benötigte ein größeres Entwicklerteam als Alaska derzeit insgesamt hat), gibt es einerseits alles, was man bräuchte, irgendwo da draußen - und andererseits zwängen eigene (in der Entwicklungsumgebung enthaltene) Komponenten auch immer dazu, sich auf bestimmte visuelle und funktionale Fähigkeiten zu beschränken. Deshalb wäre es mir grundsätzlich lieber, einfach die Möglichkeit zu haben, das zu integrieren, was der Markt ohnehin anbietet. Und das robust und in angemessener Geschwindigkeit. Damit wären schon ziemlich viele Kühe vom Eis.
Herzlich,
Tom
Tom
- Jan
- Marvin
- Beiträge: 14641
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 87 Mal
- Kontaktdaten:
Re: Wunsch-Controls
Hallo Tom,
nein, Glaubenskrieg bestimmt nicht. Deswegen hatte ich ja versucht, meine Gründe darzulegen. Und ich habe ja auch geschrieben, daß ich nicht grundsätzlich Probleme mit ActiveX habe, immerhin habe ich einige davon ja erfolgreich eingesetzt, und bei wenigstens zweien mache ich das noch immer.
Und klar, Xbase++ kann und soll nicht jede Eventualität abdecken können. Ich denke aber, eine gewisse Grundfunktionalität oder besser eine erweiterte Grundfunktionalität sollte vorhanden sein. Und die enstprechenden Schnittstellen für Erweiterungen. Wie ActiveX, aber auch andere. Aber immer in akzeptabler Geschwindigkeit und mit akzeptablem Funktionsumfang (also nicht nur rudimentär).
Klar ist aber wohl auch, das der Grundumfang im Laufe der Zeit immer umfangreicher werden wird. Das liegt in der Natur der Sache. Und es wird immer auch die Diskussion geben, wo der Grundumfang aufhört und die entbehrlichen Erweiterungen aufhören. Ich erinnere mich noch gut an die Diskussion wegen ActiveX. Wo Alaska sogar angefeindet wurde, weil die JazzAge in den Ruin treiben würden. Etwas ähnliches wird es wohl auch wegen Arctica geben. Anderseits schreien andere User nach diesen Funktionen. 100 User, 120 Meinungen und Bedürfnisse.
Ich finde es aber in jedem Fall gut daß Steffen uns fragt, was wir noch brauchen. Ob er das alles umsetzt, und ob er das so umsetzt wie wir uns das vorstellen, sei mal dahingestellt. Aber er fragt uns, und die Antworten dürften wohl recht praxisnah sein. Ich lass mich da mal überraschen, was daraus wird.
Jan
nein, Glaubenskrieg bestimmt nicht. Deswegen hatte ich ja versucht, meine Gründe darzulegen. Und ich habe ja auch geschrieben, daß ich nicht grundsätzlich Probleme mit ActiveX habe, immerhin habe ich einige davon ja erfolgreich eingesetzt, und bei wenigstens zweien mache ich das noch immer.
Und klar, Xbase++ kann und soll nicht jede Eventualität abdecken können. Ich denke aber, eine gewisse Grundfunktionalität oder besser eine erweiterte Grundfunktionalität sollte vorhanden sein. Und die enstprechenden Schnittstellen für Erweiterungen. Wie ActiveX, aber auch andere. Aber immer in akzeptabler Geschwindigkeit und mit akzeptablem Funktionsumfang (also nicht nur rudimentär).
Klar ist aber wohl auch, das der Grundumfang im Laufe der Zeit immer umfangreicher werden wird. Das liegt in der Natur der Sache. Und es wird immer auch die Diskussion geben, wo der Grundumfang aufhört und die entbehrlichen Erweiterungen aufhören. Ich erinnere mich noch gut an die Diskussion wegen ActiveX. Wo Alaska sogar angefeindet wurde, weil die JazzAge in den Ruin treiben würden. Etwas ähnliches wird es wohl auch wegen Arctica geben. Anderseits schreien andere User nach diesen Funktionen. 100 User, 120 Meinungen und Bedürfnisse.
Ich finde es aber in jedem Fall gut daß Steffen uns fragt, was wir noch brauchen. Ob er das alles umsetzt, und ob er das so umsetzt wie wir uns das vorstellen, sei mal dahingestellt. Aber er fragt uns, und die Antworten dürften wohl recht praxisnah sein. Ich lass mich da mal überraschen, was daraus wird.
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Re: Wunsch-Controls
Ich wäre erstmal dafür, dass Xbase++ 2.0 fertig wird als sich über solche Dinge Gedanken zu machen. Im Produktiveinsatz helfen mir solche Sachen eher weniger, als grundsätzliche Dinge, die sich auf alles auswirken.
- AUGE_OHR
- Marvin
- Beiträge: 12903
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 44 Mal
Re: Wunsch-Controls
hi,
vorhandene Lösungen aus dem Alaska Newsforum sollten nach dem ASCN Prinzip behandelt werden und in eine ASCN-LIB gebracht werden.
Die Frage ist nur "wer" soll das machen ... Alaska wird sich wohl kaum darum "kümmern"
was ich noch gerne hätte : aktiveX (oder .NET) Class Browser für Methoden und Property
... wenn ich bei WinDev ein ActiveX einbinde und im Editor was tippe, dann werden mir die Methoden und Property des activeX angezeigt.
sage ich dochJan hat geschrieben:Und? Wo ist da das Problem? Warum soll mann denn da nicht eine Xbase++-interne Funktion draus machen? Die dann jedem user ohne Sucherei und Download zur Verfügung steht?AUGE_OHR hat geschrieben:gibt es von Thomas Braun TrayIcon Class.
aber auch die RegClass von Thomas Braun sollte in die XppSYS.DLL
ich denke unter Wunschliste sollte das was Xbase++ noch nicht hat oder von uns User nicht gelöst werden kann, enthalten....sollte in die XppSYS.DLL
vorhandene Lösungen aus dem Alaska Newsforum sollten nach dem ASCN Prinzip behandelt werden und in eine ASCN-LIB gebracht werden.
Die Frage ist nur "wer" soll das machen ... Alaska wird sich wohl kaum darum "kümmern"
was ich noch gerne hätte : aktiveX (oder .NET) Class Browser für Methoden und Property
... wenn ich bei WinDev ein ActiveX einbinde und im Editor was tippe, dann werden mir die Methoden und Property des activeX angezeigt.
gruss by OHR
Jimmy
Jimmy
Re: Wunsch-Controls
.NET Unterstützung, das wäre was! Das ist mein größter Wunsch. Wenn ich sehe was da machbar ist kommen mir bei XBase++ die Tränen...Tom hat geschrieben:...Will sagen: Besserer (schnellerer!) Active-X-Support und die Fähigkeit, sicher und komfortabel auf .NET-Bibliotheken zuzugreifen - das wäre ein Wunsch, der sofort alle meine anderen Wünsche beseitigen würde.Sind das jetzt alle Wünsche?
War da nicht mal die Ankündiung das XBase++ auch .NET unterstützen sollte ???
Mein Vorschlag, die Erweitung der Parts sofort einstellen und die freien Resourcen in die .NET Untersützung einsetzen.
Gruß Manfred
- azzo
- Rekursionen-Architekt
- Beiträge: 483
- Registriert: So, 28. Mär 2010 19:21
- Danksagung erhalten: 11 Mal
Re: Wunsch-Controls
meine Wunsch-Controls (Xbase-Parts) sind:
- XbpRibbonBar
Multifunktionsleiste wie in Office 2007
- XbpSlider
Schieberegler
Gibt es bereits in der Prof.Subscription, aber dabei handelt es sich um ein "selbstgebasteltes",
auf XbpStatic basierendes Control. Hier ist das entsprechende Windows-Control gemeint.
- XbpTrayItem
Anzeigen und Steuern eines Symbols (Icons) im SysTray.
Die Controls sollten nicht ActiveX-basiert sein, um OCX-Control-Registrierungen zu vermeiden.
Hallo Sören,
du könntest FIVEWIN einbinden. Die Controls sind in Fivewin verfügbar.
Gruß
Otto
- AUGE_OHR
- Marvin
- Beiträge: 12903
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 44 Mal
Re: Wunsch-Controls
wie wäre GDI32 ?
ich weiss nicht wie viel davon GRA Funktionen abgedeckt werden, aber ich meine eher "Fenster" Function zum "animieren".
gut wäre auchwenn Alaska dafür eine XbPart Class als "Wrapper" implementieren würde...
ich weiss nicht wie viel davon GRA Funktionen abgedeckt werden, aber ich meine eher "Fenster" Function zum "animieren".
gut wäre auch
Code: Alles auswählen
DLLFUNCTION AnimateWindow(hwnd,dwTime,dwFlags) USING STDCALL FROM USER32.DLL
gruss by OHR
Jimmy
Jimmy