Tach,

ich komm da bissel nich ganz zurecht und wollte mal genau nachfragen was ich machen muss, damit das ganze richtig läuft und ich mir nix zerschiess.

Also entpackt isses, location is denke ich mal egal oder ?
Habs wie alle downloads aufem desktop entpackt.

Wie ich so gelesen habe muss man folgendes machen:

- setup.exe ausführen, einstellungen vornehmen.
- dann paar sachen in config einstellen:

\Settings\SharpCore\conf.xml
ShellCheck = 1

\Settings\SharpCore\Services\DDE\Settings.xml
ServiceType = 1

- SharpCore.exe starten, und dann sollte bei der frage ob default explorer nein wählen

Wenn ich das genauso mache, dann funzt es zwar, aber die taskleiste verschwindet nicht, und sobald ich alles von sharp close, dann hat er mein wallpaper in windoof überschrieben.

Achja, eine funktion welches das komplette sharp environment beenden wäre fein, weil immer jeden einzelnen Service zu beenden + Sharpdesk + sharpcore ist nervig.

Unicode character gehen immer noch nicht
Beispiel: Versucht man ein neues Folder Object in SharpDesk hinzufügen
und wählt diesen namen:

ばか　welches baka/idiot bedeutet nur als beispiel dann sieht man nur im Eingabe Feld ?? Wäre fein wenn das mal gehen würde, nur geht das mit den Standard TEdit´s nicht Ich arbeite momentan an einem System, mit den man nur noch in Delphi den classnamen in TUnicodeEdit ändern kann und somit dann unicode charas supported werden, und man die normalen strings trotzdem verwenden kann. Bin noch an der StringToUnicode und UnicodeToString routinen dran, welche aber NICHT mit Widestrings als endergebnis arbeiten, sondern mit gewöhnlichen ansistrings.

Die Taskleiste verschwindet erst sobald SharpE als default Shell registriert ist. (was aber nicht nötig ist wenn man es nur mal ausprobieren möchte bzw. wenn man nur mal SharpDesk.exe testen will)
Die Einstellung :
\Settings\SharpCore\conf.xml
ShellCheck = 1
benötigt man nur wenn man vor hat SharpE als default shell zu registrieren. (dann Frage mit Ja beantworten)

Mit dem Windows Wallpaper überschreiben läßt sich leider nicht umgehen (Ist verdammt wichtig für andere Anwendungen die die PaintDesktop funktion der win32 API benutzen). Aber das ist das gleiche wie mit dem "alles auf einmal beenden". Das sind alles nur Probleme die jetzt natürlich auftreten wenn man sichs nur mal schnell anschauen will ohne es als Shell zu registrieren. Wer SharpE dauerhaft einsetzt braucht keine funktion um alle Komponenten auf einmal zu beenden. Für den ist auch der gesammte Win32 Wallpaper Teil dann absolut uninteressant. Deshalb sehe ich da auch nicht wirklich nen Grund was dran zu ändern


Ich glaube eine Unterstützung für Unicode bringt mehr Probleme mit sicht als das es wirklich nützlich wäre. Für eine Unicode unterstützung müßte einfach zu viel umgeschrieben werden.(Unicode Unterstützung für JvSimpleXML, Edit Boxen, TBitmap32.RenderText, etc. )

Also das mit den Bitmap32 umgeschrieben ist absolut kein prob.
Das sind 4 oder 5 zeilen neuer code. :p
Ich hab das auch schon gemacht und es funktioniert prima.

und wegen dem TEdit da bin ich am coden momentan, wo man normale TEdit´s nehmen kann... halt den classnamen ändern muss auf TUnicodeEdit und schon kann man unicode schreiben.

Selbst bei den XML braucht man nix zu machen, man speichert gewöhnliche strings, und das reicht ja.
Ich werkle ja an einer routine mit dem man unicode zu gewöhnlichen strings konvertieren kann und wieder zurück.

Das Format hab ich momentan so:

Quelle Widestring: ich bin kein ばか
Ziel string: ich bin kein UC($03070,$0304B)

Im grunde muss dann nur noch die Change und Paint methode geändert werden. Leider habs ich aber bisher nicht geschafft, ein Voll Bugfreies TUnicodeEdit zu machen. Da es da irgendwie immer spinnt, sobald ich die Paint routine überschreibe

Ich arbeite jetzt schon gut ein halbes Jahr an SharpDesk, irgendwann finde ich bestimmt auch mal ein wenig Zeit um mich mit dem ganzen Unicode Zeug zu beschäftigen
Könnte aber durchaus sein das das vor der v1.0 Version(das SharpE release nach PB5) nichts wird.

Ich will auch mal ein bisschen Senf dazu zugeben.

Ich glaube einer der wohl größten Punkte ist ganz klar die Zeit. Ich sehe das ja auch an meinem Projekt. Am liebsten würde man alles gleichzeitig implementieren. Nur leider geht es nicht. Und da muss man dann ganz klar abschätzen. Was dauert wie lange und wie wichtig ist es mir. Und so etwas wie Unicode ist nicht unbedingt Lebensnotwendig. (Bitte nicht falsch verstehen ist nicht böse gemeint.) SharpDesk wird wahrscheinlich nicht so wahnsinnig häufig auf japanischen bzw. asiatischen Rechnern laufen. Und im europäischen Raum gibt es nicht so viele die asiatische Verzeichnissnamen (Dateinamen) bei sich auf der Platte haben. Sorry aber ich persönlich würde das auch äußerst niedrig priorisieren. Vor allem wo effektiv nur einer danach schreit. Ist nicht böse gemeint. Aber ich kann mir vorstellen, dass Billi da derzeit noch ne ganze Menge anderer Dinge hat die ihm wichtiger erscheinen.

Jo kann ich verstehen
Gibt wichtigeres... aber eigentlich musst du nich viel machen.
Ich kann das ja auch übernehmen, ich bau mal nen sample in den nächsten 2 wochen was ich dann mit samt quellcode poste.

hier ist noch nen tool, welches schon die geänderte Bitmap32 routinen drin hat + unicode library.

http://www.xenorate.com/final/MyUnicode.zip

Mit der Zeit und den geplanten Features ist genau das Problem,
es gibt bei so großen Projekten so verdammt viel zu tun das man eigentlich nur damit beschäftigt ist ständig ein gigantisches Sieb anzusetzen wo am Ende nur die hälfte hängen bleibt.
Und komischerweise hat bis jetzt wirkliche _niemand_ sonst(weder hier noch auf der SharpE Page) nach einer Unicode unterstützung geschrien

bei mir läufts unter WinME ohne Probleme (ich hab das ding gleich als shell istalliert wenn ich mir das system zerschiesse dann schon richtig )
Was mir aufgefallen ist das man im Statrtmenu nicht nach unten scrollen kann das wäre aber bei meinen alzu zahlreichen programmen schon praktisch
Naja ich bleib mal erst bei Litestep das hat zurzeit noch ein bisschen mehr Features auch wenn das ssich nicht von allleine wiederstartet wenns abstürzt was schon ganzschön praktisch ist..--
Übrigens hat ich mit der Funktion mal das Problem das das immer wieder die Bar gestartzet hat obwohl ich jedesmal auf no geklickt hab....

Zum nach unten scrollen im Startmenü einfach die Maus an den unteren Rand des Menüs bewegen

Warum es natürlich unter WinME überhaupt läuft ist für mich echt ein Rätsel

Jetzt mal eine Frage von mir an alle die es ausprobiert haben,
wie lange dauerte so im Durchschnitt das laden eines Themes mit Wallpaper?

Ich hab gerade einen Bericht bekommen das es auf einer 500Mhz CPU gute 3.30 Minuten dauert
Wobei allein das Wallpaper laden an die 3 Minuten gedauert hat

Kanns momentan ned testen (nach dem meine zweite Platte eben nen Crash hatte stell ich grade Daten wieder her *grrr*), aber auf meinem Rechner (Athlon XP2600+) ging das recht flott, und zwar definitiv in weniger als 20 Sekunden.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Also das laden der themes hier auf dem rechner im geschäft.
XP 2000+ 512 DDR 333 sinds gut 30 secs.

Zuhause knapp 5secs... P4 3 Ghz HT, 1024 DDR 400.

Achja betreffend Unicode, omg sag ich da nur...
Selbst nen normales TEdit unicode fähig zu machen ist unfassbar schwer und ich hänge da an soviel stellen

Das Zeichnen ist allgemein absolut kein problem, nur das schreiben geht einfach nicht so wieso soll. Man muss das gesamte TEdit nachprogrammieren, mit allen was dazugehört, tasten abfangen, messages abfangen... Cursor tasten, Löschen, Einfügen, Ausschneiden usw

Ich such schon die ganze zeit ne testcompo so ne TEdit wo alles selbst geschrieben ist, damit ich mich an irgendwas orientieren kann

@Unicode: schonmal Google gefragt? schau mal unter http://tnt.ccci.org/delphi_unicode_controls/ nach. Scheint auf den ersten Blick frei zu sein.

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

TNT Unicode Controls sind nicht compilierbar unter Delphi 5 Standard

Habe gerade die Idee mit den IconSets gesehen. Finde es auf jeden Fall sehr praktisch so etwas.

Allerdings habe ich auch etwas anzumeckern. Ich finde den Weg den du dort gehts etwas sehr unpraktisch. Allerdings kann es ja durchaus sein, dass du dafür spezielle Gründe hast. Diese Möglichkeit, so wie du sie vorgeschlagen hast, zwingt den Entwickler schon fast wieder dazu eine TStringList erzeugen zu müssen. So erstellst du kurzzeitig eine Liste in deiner DLL und musst dann, um den Text vernünftig auswerten zu können, auch wieder eine Stringliste erstellen, diese dem Text zuweisen, Die Items iterrieren und dann die Liste wieder frei geben. In meinen Augen ein wenig sehr viel Aufwand um nur mal eine Liste mit Einträgen zu transportieren! Speziell wenn du nur einen Bruchteil der kompletten Liste haben willst ist das ziemlich viel overhead. Und wenn man bedenkt, dass du diesen Text mehrmals kopieren musst (was definitiv nicht notwedig ist). Und das zerrt auf Dauer sehr stark an der Performance. Die in den Projekt ja teilweise schon zu leiden hat. Wie man so liest.

An dieser Stelle kannst du dir die ganze Stringlistgewurschtel sparen.
Die DLL exportiert zwei Funktionen.

Was dann da im Hintergrund geschieht ist erst einmal Sache der DLL. Du kannst entweder auf eine richtige Stringlist zugreifen. Die kann zum Beispiel im Initialization erzeugt und im finalization wieder freigegeben werden.
Du kannst aber auch ein konstantes Array (über const) erzeugen und dort dann dementsprechen nur die Größe, mittels Length und die Einträge über einen direkten Zugriff auf das Array auslesen und zurück geben. Das Bester wäre wahrscheinlich der Rückgabewert wäre pChar und zeigt direkt auf die Adresse eines Arrayeintrages. Somit würden nur 4 Bytes übertragen werden. Besser gehts dann kaum noch.

Wenn DLL und Anwendung jeweils Delphi sind kannst du ohne Probleme String als Typ verwenden. Andernfalls kannst du allerdings auch pChar(Stringvariable oder Arrayeintrag) verwenden und dann greift Delphi direkt über die Adresse auf die Variable zu. Dabei besteht dann keine Notwendigkeit mehr irgendetwas neu zu alloziieren und wieder von Hand freigeben zu müssen.