ActiveX und Vista

[Jan]

... woher jetzt nehmen ?

... von einem XP-Rechner, so wie ich.

Jan

[AUGE_OHR]

Hi,

Ergebnis: Auf meinem Vista-Rechner ist nicht eine einzige License eingetragen!

was hast du für eine VISTA Version ?
bist du als Administrator angemeldet bzw. rechte Maustaste "als Admin" ?

ich "merke" gerade das ich wohl Problem mit der RegClass bekommen
könnte ... unter VISTA kommt man scheinbar an "bestimmte" Zweige
gar nicht ran ... so wie ich auch nicht in diverse Root Verzeichnisse mit
Total Commander "reinkomme"... ( M$ Systemverzeichnisse ? )

Diese ganze "Rechte" und :license Geschichte unter VISTA fängt mich
langsam an zu nerven ... bald darf man als Programmierer gar nichts
mehr machen wenn man nicht M$ "Werkzeuge" benutzt

Nachtrag : XppFD.EXE fügt auch unter VISTA den :license Key ein ... wenn
man unter Option / Stettings / "Query License Key" auch tatsächlich auf
enable setzt

[brandelh]

oopps, das habe ich bisher auch nicht gemacht ;-(

allerdings frage ich mich, warum man bei M$ OCX auch noch eine Lizenz braucht, wo man doch beim BS schon jede Menge Ärger beim installieren hatte (ich hasse die Eingabe dieser Zahlen und Buchstaben ...)

[AUGE_OHR]

hi,

@JAN : welche Version benutzt du jetzt eigedlich für deinen "Progressbar" ?

anbei mal ein JPG was man mit "visual Style" machen köönte ...

[Jan]

Ähm, Jimmy,

ist das jpg jetzt irgendwo "geklaut", oder ist das eine Xbase++-Anwendung? Ich hab das nämlich noch nicht hinbekommen mit den verschiedenen Farben und dem Marquee. Die Farben sind mir ehrlich gesagt vollkommen egal, aber der Marquee interessiert mich.

Jan

[AUGE_OHR]

hi,

ist das jpg jetzt irgendwo "geklaut", oder ist das eine Xbase++-Anwendung? Ich hab das nämlich noch nicht hinbekommen mit den verschiedenen Farben und dem Marquee. Die Farben sind mir ehrlich gesagt vollkommen egal, aber der Marquee interessiert mich.

leider ist das VB Code was ich mir in VB Studio reingezogen habe. Man sieht "es geht" ...

mit der v5.x Version hab ich ja mit der :StyleClass / :StylePart schon "andere" Balken als
die "Blöcke" zeigen können und die neuen "Theme"´s die ich installiert habe sehen dem
VISTA Look schon sehr ähnlich, aber den "Marquee" hab ich immer noch nicht hinbekommen

[AUGE_OHR]

hi,

ich glaube ich bin einen Schritt weitergekommen :

a.) such mal nach Progress.AVI unter VISTA
b.) der Marquee ist "Kein Balken" sondern eine Animation
c.) der Marquee hat weder eine Position noch ein Range
sondern ein Start/Stop/Step

daraus ergibt sich die Frage : wie "bewege" ich was ?

und die Antwort lautet : Ich schicke ihm einen Event per
SENDMESSAGE/hWnd, PBM_* ...

nun sagte ich ja die ganze Zeit das bei der V6.x ein
SENDMESSAGE nicht mehr "wirken" würde aber die v6.x
hat ja definitiv kein "Visual Style" ... also ist der "grüne"
Progressbar vielleicht eine "v5.x Mogelpackung" ?

@JAN : hast du das C:\WINDOWS\system32\comctl32.ocx
von XP auf dem VISTA PC am laufen ? Wenn ja welche
Comctl32.DLL Version ?

[AUGE_OHR]

moin,

wir kommen der v6.x Sache näher ...

darum geht es :
http://msdn.microsoft.com/en-us/library ... S.85).aspx

Remarks
You can set progress bar styles, in the same way as other common controls, with CreateWindowEx, GetWindowLong, or SetWindowLong.

hm ... wir reden hier über die v6.x "Common Controls", wie unter VISTA, aber auch XP !

True, MS decided not to support themes in version 6 of it's common controls.

hm ... ist das wirklich "True" oder nur weil man die Lösung für .F. nicht "kennt" ?

Code: Alles auswählen

hwndProgress := CreateWindowEx(0, 'msctls_progress32', nil, WS_CHILD or
WS_VISIBLE or PBS_SMOOTH, 10, 30, 270, 15, hWnd, 0, hInstance, nil);

das ist nur Delphi Code für einen "normalen" Progressbar

Code: Alles auswählen

hwndXP := CreateWindowEx(0,PROGRESS_CLASS,nil,
WS_CHILD or WS_VISIBLE or PBS_MARQUEE,10,60,
270,15,wnd,IDC_XPPROGRESS,hInstance,nil);

und so sollte der "Marquee" erzeugt werden ... das ist doch ein Style ... oder ?

... blabla SendMessageA() ... dynamisch ...

hm ... und wenn ich es doch mal probiere ...

Code: Alles auswählen

#include "DLL.ch"

#define WM_USER            0x0400
#define PBS_SMOOTH         0x01
#define PBS_VERTICAL       0x04
#define PBS_MARQUEE        0x08

#define PBM_SETRANGE       (WM_USER+1)
#define PBM_SETPOS         (WM_USER+2)
#define PBM_DELTAPOS       (WM_USER+3)
#define PBM_SETSTEP        (WM_USER+4)
#define PBM_STEPIT         (WM_USER+5)
#define PBM_SETRANGE32     (WM_USER+6)
#define PBM_GETRANGE       (WM_USER+7)
#define PBM_GETPOS         (WM_USER+8)
#define PBM_SETBARCOLOR    (WM_USER+9)
#define PBM_SETMARQUEE     (WM_USER+10)

DLLFUNCTION SendMessageA( nHwnd, nCmd, wParam, lParam) USING STDCALL FROM USER32.DLL

...

oProgress := XbpProgressBar():New( oDlg:DrawingArea )
// Uncomment this line to create a 6.0-type progress
// bar, see notes above
//
oProgress:CtrlVer := 6
oProgress:Create(,, aPos, aSize )

IF oProgress:CtrlVer = 6
*  oProgress:BarStyle := XBPPRGR_STYLE_MARQUEE
   oProgress:BarStyle := XBPPRGR_STYLE_SMOOTH

   hwndPB := oProgress:hWnd

   SendMessageA(hwndPB, PBS_MARQUEE    , 1, 200)
   SendMessageA(hwndPB, PBM_SETMARQUEE , 1, 200)
   SendMessageA(hwndPB, PBM_SETBARCOLOR, 0,;
      AutomationTranslateColor( GraMakeRGBColor({076,254,076}),.F.) )

...
PROCEDURE ProgressThreadFunc( oProgress,oProz,oStatic )
   SendMessageA(hwndPB, PBM_SETSTEP   , 5,   0)
...

hm ... den "Marquee" hab ich zwar immer noch nicht, aber SendMessageA() funktioniert ja wohl
eindeutig das kann man wohl sehen !!!

*Erinnerung : Ohne MANIFEST geht nix !!!

wenn man sich nun unter http://msdn.microsoft.com/en-us/library ... S.85).aspx
die Messages ansieht so wird weiterhin mit SendMessage() = SendMessageA() ? gearbeitet ?!

hm ... und wenn ich da mal "weiter runter" gehe finde ich "Tab"(page) und bei den Messages
sind doch alle vorhanden ... also müsste theoretisch es möglich sein den "orangen" Leuchtbalken
"anzufordern" ... (noch nicht ausprobiert)

aber bleiben wir beim Progressbar

hm ... war da nicht noch ein "Trick" ...

Has anyone been able to get this setting for Progress bar type working...Yes i am using Windows XP SP2 and have included the commctl.h and InitCommonControl() ... (forgive me if i didnt spell out their exact namings -- too lazy to check) ... I even have .net 1.1 installed. I use:

SendMessage(hwndProgressbar,PBM_SETMARQUEE ,TRUE,500);

und vom selben User etwas später :

Actually i figured it out...Turns out since i had the progress bar as a resource instead of using the CreateWindowEx(..) i had to use SetWindowLongPtr(..) to set the PBS_MARQUEE style for this control...now it works Yipeee to me!

toll ... für ihn den die "Lösung" rückt er nicht raus ... aber irgendwas mit SetWindowLongPtr(..) ???
http://msdn.microsoft.com/en-us/library ... S.85).aspx
und was nun ? das ist mir "zu hoch" ...

also zurück zum Anfang ... da war doch noch :

GetWindowLong, or SetWindowLong.

kommt mir doch irgendwie bekannt vor ... woher kenne ich das bloss ... ?

Code: Alles auswählen

FUNCTION SetWindowLayered(hWnd,lActive)
LOCAL lExStyle := GetWindowLongA(hWnd,GWL_EXSTYLE)
   SetDefault(lActive,.T.)
   IF lActive
      IF !(lExStyle $ WS_EX_LAYERED)
         lExStyle := lExStyle+WS_EX_LAYERED
         SetWindowLongA(hWnd,GWL_EXSTYLE,lExStyle)
      ENDIF
   ELSE
      IF (lExStyle $ WS_EX_LAYERED)
         lExStyle -= WS_EX_LAYERED
         SetWindowLongA(hWnd,GWL_EXSTYLE,lExStyle)
      ENDIF
   ENDIF
RETURN (NIL)

... Fortsetzung folgt

[brandelh]

Actually i figured it out...Turns out since i had the progress bar as a resource instead of using the CreateWindowEx(..) i had to use SetWindowLongPtr(..) to set the PBS_MARQUEE style for this control...now it works Yipeee to me!

toll ... für ihn den die "Lösung" rückt er nicht raus ...

also ich lese das so, dass der Austausch der aufgerufenen Fensterfunktion:

CreateWindowEx(..) --> SetWindowLongPtr(..)

den Unterschied gemacht hat.

Warum SENDMESSAGE nicht funktionieren soll, kann ich aber nicht verstehen, das ist doch die zentrale Funktion in Windows, das doch voll auf messages aufgebaut ist oder ?
Ich kann mir höchsten vorstellen, dass eine Nachricht als solche jetzt nicht mehr oder nicht mehr gleich reagiert.

[AUGE_OHR]

Warum SENDMESSAGE nicht funktionieren soll, kann ich aber nicht verstehen, das ist doch die zentrale Funktion in Windows, das doch voll auf messages aufgebaut ist oder ?
Ich kann mir höchsten vorstellen, dass eine Nachricht als solche jetzt nicht mehr oder nicht mehr gleich reagiert.

ich bezog mich auf das Zitat vom "Microsoft MVP Visual Basic" Mann siehe
http://www.xbaseforum.de/viewtopic.php? ... sic#p27340

[brandelh]

Hallo Jimmy,

das ist doch genau das was ich meinte. SENDMESSAGE als solches funktioniert !

Windows Common Controls 6.0 (included with VB6) is its own implementation of
the common controls and is not dynamically linked to the Common ControlsDLL.

aber die 6.0 sind komplett neu geschrieben und greifen nicht auf die 5.x DLL zu.
- dazu habe ich vor kurzem gelesen, dass ein OCX im Prinzip auch nur eine DLL ist, allerdings kann sich das Teil selbst registrieren (falls ich das richtig verstanden habe).

Therefore, APIs (messages, event notifications, etc.) may or may not work
with it. It just depends on whether these were written into the OCX.

hier hat er sich unglücklich ausgedrückt, aber es kann nur bedeuten:
Alles was in 6.0 eingebaut wurde funktioniert wie bisher mit sendmassage,
aber nicht alles was in 5.x enthalten war ist auch hier noch enthalten bzw. verhält sich gleich.
Das ist ja auch logisch, was man dem Teil nicht beigebracht hat, kann es nicht.

For any message, etc. that is specific to WinXP and later, you'll have
to be sure to use a manifest so the 6.0 version of the DLL is used.

das ist jetzt interessant.
Entweder er widerspricht sich hier selbst oder man könnte es so verstehen:

* die neue OCX basiert ja nicht auf einer DLL und somit kann sich der Satz darauf nicht beziehen.
* es muss eine 6.0 DLL+OCX geben, die man per manifest aktivieren muss, wenn man die neuen XP Sachen haben will.
* bei den anderen Sachen scheint es egal zu sein wie man dran kommt.

ComCtl32.dll finde ich in :
- c:\windows\system (alte Vorgänger ? - nur auf einem Rechner, vermutlich nachinstalliert)
- c:\windows\system32 (Version 5.82.2900.2180 XP-SP2 und *.5512 XP-SP3 oder nachinstalliert)
keine OCX dazu !

Auf dem XP-SP2 ohne nachinstallierte ComCon 6 finde ich keine
MSCOMCT*.OCX Dateien !

auf dem XP-SP3 mit nachinstallierten CommCon 6 finde ich :

MSCOMCTL.OCX (6.1.97.86) -> c:\windows\system32
MSCOMCT2.OCX (6.1.97.82) -> c:\windows\system32
hierzu gibt es keine DLL ...

allerdings finden sich im Ordner:

c:\Programme\Microsoft Visual Studio 9.0\Visual Studio Tools for Office\PIA\Office11
und
c:\Programme\Microsoft Visual Studio 9.0\Visual Studio Tools for Office\PIA\Office12

je die gleiche MSCOMCTL.DLL ???

Das ist doch alles Murks !

Wie schon einmal geschrieben, kein Wunder dass M$ hier alles auf .NET umstellen will.
Bei dem Durcheinander

Zu der Aussage oben müsste man natürlich auch die Frage gelesen haben.
Wahrscheinlich war es eine ... mein alten VB Programm funktioniert mit dem neuen VB auf dem neuen Win... nicht mehr so wie ich es erwartet habe ...
Und dann verstehe ich die Antwort so:

M$ hat neue Dinge eingebaut, weil du die brauchst, dann musst du sie auch nutzen ...

[Martin Altmann]

Moin Hubert,

MSCOMCTL.OCX (6.1.97.86) -> c:\windows\system32
MSCOMCTL.OCX (6.1.97.82) -> c:\windows\system32

das ganze Thema läuft zwar ziemlich an mir vorbei, aber das kann nun definitiv nicht sein! Copy&Paste-Fehler

Viele Grüße,
Martin

[brandelh]

Moin Hubert,

MSCOMCTL.OCX (6.1.97.86) -> c:\windows\system32
MSCOMCTL.OCX (6.1.97.82) -> c:\windows\system32

das ganze Thema läuft zwar ziemlich an mir vorbei, aber das kann nun definitiv nicht sein! Copy&Paste-Fehler

Viele Grüße,
Martin

Hallo Martin,

genau ich habe es auch oben verbessert:

MSCOMCTL.OCX (6.1.97.86) -> c:\windows\system32
MSCOMCT2.OCX (6.1.97.82) -> c:\windows\system32

[AUGE_OHR]

hi,

das ganze Thema läuft zwar ziemlich an mir vorbei ...

ok also noch mal kurz das "Problem" :
a.) Es gibt die M$ Common Controls in der Version v5.x und v6.x
b.) Alaska bezieht sich z.b. bei den "visual Styles" auf die v5.x
c.) unter VISTA wird "default" mit der v6.x gearbeitet
d.) Alaska "meint" die v6.x könnte "kein visual Style"

nun wage ich mich mal vor und behaupte : IMHO diese Aussage d.) ist FALSCH !!!
Begründung : "üblicherweise" wird per SendMessage() solche Styles, Farben und sonstige Propertys
eingestellt.

... nun bin ich durch die Aussage von Alaska und dem MVP Mann davon ausgegangen das es nicht
gehen würde und habe es nicht ausprobiert. Gestern Nacht dachte ich mir jedoch versuche es
doch wenigstens mal und siehe da : SendMessageA() funktioniert mit der v6.x Version ??? mit

Code: Alles auswählen

 hwndPB := oProgress:hWnd

 SendMessageA(hwndPB, PBM_SETBARCOLOR, 0,;
      AutomationTranslateColor( GraMakeRGBColor({076,254,076}),.F.) )

habe ich jetzt einen grünen Balken, wie unter VISTA, aber leider noch nicht den Marquee .

Nun "vermute" ich das Alaska evtl. nicht beachtet das die v6.x auf "andere" :StyleClass / StylePart
zugreift als die v5.x ( http://msdn.microsoft.com/en-us/library ... S.85).aspx ) was ich
noch überprüfen muss. Wenn ich schon mit "visual Style" arbeiten "muss" dann aber bitte gleich
richtig. Deshalb bin ich hinter dem "Marquee" hinterher denn wenn ich den schaffe hab ich den
Beweis das es doch mit den Common Controls v6.x geht und man auch unter VISTA "visual Style"
für Xbase++ einsetzten kann.

[brandelh]

Hi Jimmy,

wenn Alaska sagt, dass alles geht und dann geht etwas nicht, dann
beschwert man sich dort. Zerlegt wie beim VBA Mann ...

Die Implementierung der V5 Messages arbeitet nicht immer fehlerfrei mit V6,
also geht es nicht

[Martin Altmann]

Hallo Jimmy,
keine Sorge - ich meinte nicht, dass ich das Thema nicht verstehe oder Euer Problem nicht nachvollziehen kann...
Ich meinte eher, dass es mich derzeit nicht betrifft und ich dem deshalb keine größere Aufmerksamkeit schenke.

Viele Grüße,
Martin

[AUGE_OHR]

hi,

Ich meinte eher, dass es mich derzeit nicht betrifft und ich dem deshalb keine größere Aufmerksamkeit schenke.

noch nicht, aber spätestens wenn du den "Servicel Level 1" bekommst hast, "siehst" du
das "Problem", das deine Xbase++ Application auf einmal optisch "sch..se" aussieht !
Das "verdanken" wir ja nun Alaska die "endlich" auf "visual Style" gekommen sind.

Doch was nützt dir das ganze wenn du VISTA als OS() hast und du auch mit "visual Style"
nichts machen kannst weil Alaska es nicht unter VISTA zum laufen bekommt und behauptet
es ginge nicht ?

Ich glaube deshalb das Alaska die "visual Style" "nicht richtig" implementiert hat, da nur die
Common Controls v5.x aber nicht v6.x beachtet werden welche für VISTA zuständig sind.
Übrigen kann man unter XP natürlich auch die v6.x verwenden und IMHO gibt es "visual Style"
auch in der v6.x Version und Manifest geht auch von der v6.x aus.

Was ich nun brauche ist Hilfe um die These weiter zu untermauern und dazu hab ich auch im
Alaska Forum einen Thread gestartet. Ich muss es also erstmal "schaffen" um dann Alaska mit
der Frage zu konfrontieren "das da was fehlt" und ggf. des "Beweis" antreten zu können.

Deshalb denke ich das es jeden betrifft der in Zukunft mit der "aktuellen" Version von Xbase++
arbeiten will und nicht ein "grausames" optisches Ergebniss haben möchte den der "Workaround"

Code: Alles auswählen

UseVisualStyle := .F.

ist doch ein schlechter Witz.

[brandelh]

hi,

Ich meinte eher, dass es mich derzeit nicht betrifft und ich dem deshalb keine größere Aufmerksamkeit schenke.

noch nicht, aber spätestens wenn du den "Servicel Level 1" bekommst hast, "siehst" du
das "Problem", das deine Xbase++ Application auf einmal optisch "sch..se" aussieht !
Das "verdanken" wir ja nun Alaska die "endlich" auf "visual Style" gekommen sind.

Doch was nützt dir das ganze wenn du VISTA als OS() hast und du auch mit "visual Style"
nichts machen kannst weil Alaska es nicht unter VISTA zum laufen bekommt und behauptet
es ginge nicht ?

wenn ich Martin recht verstanden habe, hat er im Programm entweder ein reines Web-Frontend bzw.
ist sehr sparsam mit den 'erweiterten Möglichkeiten' von ActiveX Controls - ähnlich wie ich

Was ich nun brauche ist Hilfe um die These weiter zu untermauern und dazu hab ich auch im
Alaska Forum einen Thread gestartet. Ich muss es also erstmal "schaffen" um dann Alaska mit
der Frage zu konfrontieren "das da was fehlt" und ggf. des "Beweis" antreten zu können.

mal sehen wie lange du Antwort bekommst

Du machst dich ja fast so unbeliebt wie ich bei meiner Aussage in Berlin ... (XUG Treffen, nicht Devcon)

[Martin Altmann]

Hey,
ich kann doch von hier aus dem Büro nicht an den Newsserver - nun macht ihr mich ja neugierig!
Jimmy, wie ich bereits schrieb: Für mich ist das derzeit kein Thema! Mein Kunden haben alle noch XP und dem einen, der zu Vista wollte, habe ich das ganz schnell ausgeredet.
Ich will auch Deinen Einsatz gar nicht kleinreden - ich finde das sehr gut! Davon können viele nur profitieren - insofern weiter so! Und sei es nur, um anderen zu zeigen: Es geht doch - auch mit Xbase++!
Sicher wird auch bei meinen Kunden irgendwann einmal Vista kommen (und Hubert, ich rede jetzt von meiner GUI-Anwendung - nicht die Webimplementation, da ist das eh' egal!), aber da ich ja auch XClass++ nutze, partizipiere ich da ja enorm von den Anstrengungen, die Dieter und Marcus unternehmen
ActiveX nutze ich bisher nur in Form des eingebundenen Office-Assistenten (hatte ich ja Jan mal kurz in Herford gezeigt).
Ich werde demnächst auch im Prinzip das XbpRtf() einbinden (mal sehen, wann ich dazu komme - eigentlich wollte ich das ja noch in diesem Jahr schaffen, aber es steht noch so viel wichtigeres auf der Agenda...), aber auch da nutze ich einen Wrapper von XClass++, so dass ich damit kaum Arbeit habe.

Viele Grüße,
Martin

[brandelh]

Hey,

... (und Hubert, ich rede jetzt von meiner GUI-Anwendung - nicht die Webimplementation, da ist das eh' egal!) ...

ich hatte doch gar nicht behauptet, dass du keine GUI hättest

Aber wenn du intensiv ActiveX im Einsatz hättest, bzw. damit Probleme, hättest du dich in dem Thread bisher anders verhalten

Ich selbst habe bisher überhaupt keine ActiveX im Produktiveinsatz, außer dem Excel Export auf meinem eigenen Arbeitsrechner.
Der ist zwar mit ActiveX recht träge (wir hatten ja einen Bericht wie es auch schnell geht ) aber diese Listen sind meist kurz
und ich muss sagen, so ein Excel Ergebnisblatt mit beiliegenden Erläuterungen auf dem Tab dahinter, macht doch viel mehr her als das was ich per Hand aus meinen Auswertungslisten gebastelt habe - einfacher ist es auch noch

Und dann hat irgendwer das Kalender-Control erwähnt (wer war das wohl ...) und ich denke mir, das könnte ich in meine Datums-SLE einbauen, für die die mit der Maus arbeiten wollen. Finde ein ZIP Beispiel und muss feststellen, dass es zwar eine Methode zum Setzen der Sonn- und Feiertage gibt, aber die einfach nichts macht !

So, mehr Aktien habe ich auch nicht im Geschäft ...

PS: neuerdings verwende ich auch Hintergrundgrafiken im Programm, das Auge isst halt doch auch mit

[AUGE_OHR]

hi,

aber da ich ja auch XClass++ nutze, partizipiere ich da ja enorm von den Anstrengungen, die Dieter und Marcus unternehmen

aber auch die beiden können nicht "zaubern" und wenn die Schnittstelle in Xbase++ nicht
implementiert wurde gibt es auch keinen "visual Style" für VISTA. ( nicht zu verwechseln
mit Theme, was auf alle XbParts "wirkt" wenn man ein Manifest angibt )

ActiveX nutze ich bisher nur in Form des eingebundenen Office-Assistenten

Kein XbpToolbar() ? Kein XbpStatusbar() ?
... aber doch XbpDialog(), XbpTabpage(), Xbplistbox() etc. ... woraus sind die wohl "gebaut" ???
Im Grund sind das doch alles "nur" Xbase++ "API-Wrapper" die auf die Windows DLL zugreifen.

Deshalb denke ich : Es ist mit Xbase++ ALLES möglich ... es hapert bloss an der "richtigen"
Implementierung (oder undokumentierten Methoden)

Witzig finde ich das jetzt erst dahinter komme, weil hier im Forum von Jan/Progressbar und Hubert/
Monthview, 2 x Probleme verdeutlicht wurden, die mein "eigentliches" Problem mit "visual Styles"
beinhaltet. Deshalb bin ich auch darauf "angesprungen" da ja Alaska genau diese beiden "Probleme"
auf der CD "release"(d) hat und man sie darauf "festnageln" kann. Die Beispiele verlangen nach der
v6.x Version genauso wie im Manifest immer 6.0.0.0 drin stehen hat.

...
bislang gab es ja die COMMCTRL.H und die TMSCHEMA.H wo man die in der Service Level 1
gültigen :StyleClass und :StyleParts findet. Diese fangen alle mit TM_ an.

Ich bin ich gerade dabei mir das "Windows SDK for Windows Server 2008 and .NET Framework 3.5"
down zu loaden weil diese wohl erst die v6.x Konstanten enthält. Diese fangen mit TDM_ an.
...

Es gibt doch C:\Alaska\XPPW32\source\SYS\axctrls.prg

Dort wird uns nicht nur der Source zu den in Xbase++ v1.9.331 "neuen" Futures wie XbpToobar(),
XbpStatusbar() geliefert sondern die beiden haben auch "beide Licencen" für die v5.x und v6.x
(der Rest ist nur v5.x), aber weder bei XbpToolbar noch bei der XbpStatusbar kann man einen
"visual Style" setzten. Die Styles selbst ist vorhanden und kann auf andere XbParts gesetzt
werden ( siehe mein buntes Progressbar v5.x Beispiel ). Es geht doch, also wat den nun ...

... und genau dieses "durcheinander" versuche ich nun auf den Punkt zu bringen.
Erst macht man uns den Mund wässrig und wenn man dann mal den Level geschafft hat und
"mehr" will dann heisst es auf einmal "es geht nicht" ???

... geht nicht gibt es nicht ... Wunder dauern eben etwas länger ...

[Martin Altmann]

Hallo Jimmy,

... geht nicht gibt es nicht

yup! Oder auch: "Geht nicht" heißt "will nicht"!
Statusbar und Toolbar nutze ich bereits seit XBase++ 1.1 - und zwar die XClass++-Pendants
Mach' ruhig so weiter - haben wir doch schon einen schönen Vortrag für unser geplantes IdXF++-Treffen

Viele Grüße,
Martin

[AUGE_OHR]

hi,

Mach' ruhig so weiter - haben wir doch schon einen schönen Vortrag für unser geplantes IdXF++-Treffen

... wie ... muss ich schon wieder "ran"
... ich bin doch selbst Newbie in der Sache und frage hier dauernd nach irgendwelchen Sachen ...

was soll ich euch von "unnützen" v5.x "visual Style" erzählen wenn ich nicht die Lösung für v6.x
habe ... das ist ja fast wie in der Schule wo man "Wissen von gestern" vorgesetzt bekommt ...

wenn Alaska, unter M$ OS(), auf .NET setzten würde wäre das wohl das "Wissen von morgen",
aber es würde mir ja schon reichen wenn wir das "Wissen von heute" bekämen damit wir unsere
Xbase++ Applicationen

The main focus of this service level is to add support for the
Windows Vista and Windows Service 2008 platforms to Xbase++.

offtopic : irgendwie habe ich vorhin den Connect verloren und ich dachte naja die Msg ist weg.
nun gehe ich mit Firefox wieder online und er ist genau an dem Stand !!! incl. Text !!! WOWWW

[Martin Altmann]

Jimmy,
was heißt Du musst schon wieder? Du darfst schon wieder
Außerdem ist es bis dahin ja noch ein wenig hin - gute sechs Monate, wenn es beim jetzigen Terminfavoriten bleibt. Und bis dahin fließt noch viel Wasser die Spree (oder von mir aus auch Elbe) herunter!
Bis dahin bist Du bestimmt fit in dem Thema - Du weißt doch: erst wenn man was erklären kann, hat man es selber begriffen

Viele Grüße,
Martin

[AUGE_OHR]

hi,

hab diesen Beitrag gelöscht, da ich den an Teil 3 der Lösung anhängen will

Nachtrag : Ich merke gerade das viele Links von mir auf dieser Seite nicht richtig funktionieren.
Es sind die mit dem (VS.85).aspx