hi,
grundsätzlich scheinen alle Samples der v350 unter Win7 zu laufen, aber der Bildschirm aufbau
wirkt irre langsam ...
unter Win7 geht es auch erst mit 128KB und DX9 los, aber auch der Chipsatz muss wohl
bestimmte Kriterien erfüllen. Eine ATI 9000 AiW hat er erkannt und auch die WDM TV
Komponenten installiert, aber beim "Sende Suchlauf" meint er dann man müsste 64KB
haben was die AiW eigentlich hat ... aber der WMP lief
Dann die AiW 64KB gegen eine Sappire ATI 9000 128KB getauscht. Auch die wurde erkannt
und Video lief auch, aber trotzdem Leistungsbewertung = 1 weil er die 128KB GFK RAM nicht
findet ? DX9 Shader ?
ok, die Hardware ist nun wirklich "alt", aber Win7 läuft damit recht flott (selbe Hardware läuft
mit VISTA nur "kriechend" ) nur eben nicht wenn ich eine Xbase++ GUI Applikation aufrufe
bei einem XbpBrowse kann man wie bei VISTA "zugucken" wie er die Columne von rechts nach
links und oben nach unten "Cell" für "Cell" aufbaut ... unter VISTA wirkt ja alles langsam und
da fällt es mit Xbase++ auch nicht auf, aber unter Win7 wirkt alles recht schnell nur Xbase++
fällt dagegen extrem "auf" ... 2D Grafik, damit macht der Tualatin 1,1Ghz schlapp und hängt
bei 100% ... sonst so 40-60%(!) bei WMP
das einzige was richtig gut funktioniert sind die Codejock activeX OCX.
Der Calender arbeitet richtig gut und keine Probleme beim "moven" oder "resize" von Terminen.
Interessant fand ich es nun wenn ich mit dblclick die Detail Ansicht aktiviert habe:
Das XbpDialog Fenster und die XbParts wurden im "Zeitlupentempo" aufgebaut ...
zuerst der Rahmen mit der Titlebar, aber noch ohne Icon, Caption oder Min/Max/Close Buttons,
also zum "durchgucken". Dann füllte sich die :drawingArea "grau" und wurde danach "eingefärbt"
mit meiner SetColorBG() Farbe. Die SLE gehen "normal" aber ein XbpPushbutton oder XbpCombox
dauerten "ewig" sodas ich die alle zum testen alle ausge"*"nt habe.
fast noch interessanter der "Workaround" : man verwenden CodeJock SkinFramework
bis auf meine Ownerdraw XbpPushbuttons wurde das Detail Fenster "per Skin sofort" aufgebaut !
Ich habe ja auch den Thread WPF und WFC (
http://de.wikipedia.org/wiki/Microsoft_ ... on_Classes)
angefangen wobei es weniger wegen der Optik ist, sondern das die "Common Controls" ja nicht
"Direct X fähig" sind und wir echt Probleme schon jetzt haben wenn wir "viele" XbParts in einer
Maske verwenden wollen.
Auch die Umfrage : "was wollen wir von Alaska" bekommt für mich nun eine neue Priorität, den
ich werde das Gefühl nicht los das Win7 "schneller kommt" als manch einer denkt. Die "beta" ist
so unverschämt gut das eigentlich nur noch die Sprach Resourcen vollständig in Deutsch über-
setzt werden "müssten" ... ok das selbe Treiber "Problem" wie bei VISTA, aber die Treiber laufen!
Codejock zeigt ja wie es mit der WPF / WFC funktioniert und die *.OCX sind ja auch nur DLL
"Wrapper" zu den .NET Runtime DLL die man seit XP so auf seinem PC hat. Auch habe ich beim
googlen eine Menge activeX Open Sourcen zum Thema gefunden ... alles in C
Wenn es also Ribbonbars, Skin, Treeview, Listview etc. als activeX Open Source gibt müsste
es Alaska doch auch schaffen eine Xbase++ Schnittstelle zu bauen ?!
Da Alaska zugesagt hatte im Falle von Codejock aktive mitarbeiten zu wollen und ja eh das
"Problem" mit IsThemeActive() und SkinFrameWork existiert, wäre es JETZT vielleicht der
richtige Zeitpunkt um einen Schritt für UNSERE Zukunft zu machen.
Ich denke das wir mit unseren XbParts echte Probleme bekommen werden wenn wir von Alaska
nicht bald DX fähige XbParts bekommen die von der GFK Hardware unterstützt werden !
Deshalb müsste wir Alaska verstärkt auf das (sicherlich bekannte) Problem hinweisen und
dafür sorgen das es in der "todo" Liste eine höhere Priorität bekommt !
