Hallo

Können mit Delphi auch Programme für Pocket-PC´s programmiert werden und falls ja welche Zusätze zu Delphi 6 Enterprise werden gebraucht ?

Gibt es hierzu Literatur?

Vielen Dank für alle Tips

Dürfte nicht gehen. Der Delphi-Compiler kann keinen Code für diese Pocket CPU's generieren.

Schade

Womit kann man den die Pocket-PC´s programmieren?
Ich kann mich dunkel erinnern, dass es mit Visual Basic gehen soll - stimmt das oder brauch man dafür eine spezielle Software?

Ist zu erwarten, dass das in Entwicklung befindliche Delphi.NET hierfür geeignet sein wird

Hallo,

es gibt ein Pocket-PC SDK von Microsoft. Dieses enthallt embedded Visual Basic und embedded Visuall C++. Wenn ich mich recht entsinne dann kann kostenlos bei M$ runtergeladen werden, musst bei denen mal suchen. Wichtig ist zu wissen für welchen Pocket-PC du Programmieren willst. Denn PPC ist nicht gleich PPC und Win Ce auch nicht gleich Win CE. Wenn du z.B. für Pocket PC 2002 etwas schreiben willst, benötigst du dafür eine Erweiterung für das oben beschriebene SDK. Die implementationen der verschiedenen Technologien unterscheiden sich auch teilweise von Platform zu Platform, es genügt also häufig nicht dein Quelltrext für andere Platforman zu Compilieren, dun musst den Code anpassen.

Es gibt ein .NET für Pocket PCs. Ich habe mich mit diesen noch nicht beschäftigt, bezweifle aber das es mit dem großen .NET gleichzieht. Daher wirst du wahrscheinlich auch deine "normalen" .NET Anwendungen nicht einfach auf den .NET fähigen PPC überspielen können, sondern eine eigenentwicklung für diese schreiben müssen. Das ergibt sich aber uch allein aus gründen des Designs. Denn ein Fenster, das du für einen 19 Zoll Monitor entwirfst, wird auf dem PPC eher unübersichtlich sein.

Gruß
Klabautermann

Hallo!

Hier mal eine Ausschnitt aus dem MSDN Library for VS .NET 2003:

MSDN Library hat folgendes geschrieben:

Für Geräteanwendungen verwenden Sie die gleiche Visual Studio .NET-Umgebung wie bei der Entwicklung von Desktopanwendungen. Einige Unterschiede zeigen sich jedoch bei der Auswahl von Geräten. Beispiel: Die Visual Studio-Umgebung bietet zusätzliche Tools für die Herstellung einer Verbindung zu einem Remotegerät und für das Debuggen auf diesem Gerät. Neben einem Projekttyp und einer Vorlage müssen Sie bei der Projekterstellung ein Gerät auswählen, auf dem die Anwendung ausgeführt und gedebuggt werden soll. Das Gerät kann entweder ein physisches Gerät sein, das mit dem Entwicklungscomputer verbunden ist, ein vernetztes Gerät oder ein Geräteemulator, der auf dem Entwicklungscomputer ausgeführt wird. Die Klassenanzahl sowie die Member der Klassen unterscheiden sich von denen, die für die Entwicklung von Desktopanwendungen verfügbar sind. Für Geräte, die .NET Compact Framework verwenden, sind weniger Klassen verfügbar (z. B. werden Web Forms, Remoting, Messaging, Verwaltung und Drucken nicht unterstützt), und die Enumeration von Klassen ist typischerweise von Plattform zu Plattform verschieden. Welche Klassen verfügbar sind, können Sie in der Dokumentation, mit Hilfe von Intellisense oder im aktiven Projekt mit Hilfe des Objektbrowsers von Visual Studio feststellen. Wie bei Desktopanwendungen können Sie auf systemeigenen Code zugreifen, indem Sie Plattformaufrufe verwenden. .NET Compact Framework bietet beschränkte Unterstützung für COM-Interop. Es unterstützt keine Erstellung von COM-Objekten in verwaltetem Code oder die Zusammenarbeit mit ActiveX-Steuerelementen. Unterschiede bestehen auch bei bestimmten sprachspezifischen Elementen. Beispielsweise werden nicht alle Visual Basic-Schlüsselwörter für Desktopanwendungen unterstützt. Manche Codeausschnitte, die in der Visual Studio .NET-Dokumentation für Desktopprojekte bereitgestellt werden, können in Geräteprojekten Buildfehler auslösen. Um die fertigen Anwendungen zu verteilen, können Sie in einem Geräteprojekt eine CAB-Datei generieren, anstatt ein eigenes Weitergabeprojekt erstellen zu müssen. Bestimmte Designaspekte sind zu berücksichtigen, z. B. die Gegebenheiten des Geräts, der Stromverbrauch, Speicherplatzbeschränkungen und andere Faktoren, die bei der Desktopentwicklung keine Rolle spielen.

Wenn man sich die Detailunterschiede zwischen dem normalen Framework und dem Compact Framework anschaut, scheinen die Unterschiede jedoch gravierender zu sein, als der obige Text vermuten lässt. So unterstützt das Compact FRamework keine Array-Untergrenzen die nicht Null sind, bei Gleitkommaberechnungen wird bei Werten die nahe Null sind wohl eher mal eine tatsächliche Null ausgegeben, usw. Leider weiß ich nicht, ob das Library online verfügbar ist und die Tabelle ist zu lang, als dass ich sie hier posten könnte.

Ich hoffe, Dir trotzdem etwas geholfen zu haben.

MfG
Peter

Hallo,

Peter Lustig hat folgendes geschrieben:

Wenn man sich die Detailunterschiede zwischen dem normalen Framework und dem Compact Framework anschaut, scheinen die Unterschiede jedoch gravierender zu sein, als der obige Text vermuten lässt.

das deckt sich inetwa mit meinen (.NET freien) Erfahrungen mit Embeddet Visual C++. Dort wird auch damit geworben, dass eine Untermenge der MFC zur verfügung steht und sowiso alles easy sein. In der Praxis stellt sich heraus das die Untermenge der MFC recht klein ist und zum Teil von der echten MFC abweicht. Desweiteren muss man häufig auch APIs zurückgreifen, die sich Teilweise je nach verwendeter Betriebsystemversion und Processor stark unterscheiden bzw. nicht vorhanden sind. Mit den System Pocket PC 2002 konnte man recht gut arbeiten. Dort ist die API recht anständig, es gibt z.B. dinde wie Hooks und man kann auch mal 'ne E-Mail verschicken (per COM-Objekt). Desweiteren sollte dieses nur noch ARM-Processoren unterstützen, was die Entwicklung leichter macht. Einige dieser Probleme werden hoffendlich vom Compact Framework gelöst, aber mit sicherheit nicht alle.
Wer sich mit PPC-Programmierung beschäftigen will, sollte nciht erwarten, dass das so gut klappt wie auf dem PC. Denn erstens haben die kleinen Apperate beiweiten nicht so viel leistung (sowohl Physikalich als auch vom Betriebsystem) zweitens sind sie noch nicht so genormt (siehe Prozessorproblematik) und drittens sind alle Technologien noch relativ jung und somit mit Kinderkrankheiten behaftet. Also, PPC Programmierung ist ein kleines Abenteuer und wie Peter Lustig ja bestätigte ist es das auch immer noch.
Es gibt ein paar Tools, die diese Probleme umgehen wollen (z.B. AppForge), diese bieten dann aber meist nur den kleinsten gemeinsammen nenner und sind daher für Anspruchsvollere Projekte nciht geeigent.
Daraus ergibt sich auch, das selbst kleinere Projekte schon ziemlich in Arbeit ausaten, weil man so manche Klippe umschiffen muss.

Gruß
Klabautermann