![]() |
Ein Tag im Leben eines FMX-App Programmierers...
Aufgabenstellung Badgenummer unter iOS-8 setzen...
08:20 Uhr frohen Mutes die VM gestartet. Schnell erst checken ob es eine Antwort zum gestrigen Threadthema gibt… Nein… Mist… Also nochmal im Source nach schauen… - Sollte klappen. Hatte ich das schon getestet? <F9>Ping e800002D: Starten Sie Ihr iOS-Gerät neu… Na toll fängt ja gut an (Und noch keinen Kaffee) iPhone direkt mal mit auf die neue Version aktualisieren… SDK-Aktuallisieren - Das Application Directory bla bla bla starten Sie den XCodeOrganizer – Ok dann starten wir den mal… - Roedel Roedel Roedel – Devicemanager starten – Roedel Roedel Roedel das iPhone ist beschäftigt… - Ach ja wo mit den… Steht doch nur ganz unschuldig in der Ladehalterung. SDK-Aktuallisieren - Das Application Directory bla bla bla starten Sie den XCodeOrganizer – Hab ich doch… - OK SDK löschen… Neues SDK… Lokalen Dateizwischenspeicher aktualisieren… - OK Keine Fehlermeldung. <F9>Weitergeben… Erfolg – Aufrufen von… IDE Weiß… Programm reagiert nicht… OK, Out of memory… XE8 neu starten. <F9>Weitergeben… Erfolg – Aufrufen von… Sanduhr… “Schwerer Debugger-Fehler: Gerät antwortet nicht. Der Debug-Vorgang wird beendet. Prozess kann nicht erzeugt werden: „Zeitüberschreitung beim Verbinden mit den Gerät“ – Und jetzt… OK Versuchen wir den 3er Trick… - iPhone reseten - XE8 neu starten… - PAServer neu starten – PAServer will ein Return… Wo ist die Mac-Tastatur? OK Return EIdCouldNotBindSocket: Socket konnte nicht gebunden werden. Adresse und Port werden bereits verwendet… Ach ja? Eine tote Instance vom PAServer? OK Mac neu Booten…(10:18 Uhr Und immer noch keinen Kaffee) Nein ich will nicht die blöde Quick Tour für die App “Fotos“ PAServer starten – Return – (Warum hat eigentlich das blöde „Developert Toll Access…“ Fenster nie den Focus auf das Passwort?) <F9>Linken… Weitergabe… Aufrufen… „Can’t start debugserver on device – device support image was not mounted… OK das ist neu… Und jetzt? XCode starten – hmm device ist da… OK Doof ist der 2x das gleiche macht und einen Unterschied erwartet…Oder? <F9>Linken… Weitergabe…Aufrufen… App da… (Also doch nicht so doof) Attempting to badge the application icon but haven’t received permission from the user to badge the application Prozess… Sollten mich die ganzen Fehlermeldungen im PAServer interessieren? NICHT JETZT… Weiter im Text Keine Verbesserung… Nochmal die Beispiel App versuchen… Warum hatte ich das im Simulator getestet… Ach ja richtig die DProj Datei ist ja defekt und hat iOS Device32 nicht mit dabei – und natürlich kann man die Plattform nicht hinzufügen… Aktuelles SVN Repo versteht sich… Also Notepad++ <Platform value="iOSDevice32">True</Platform> <F9>Fehler sind aufgetreten. Missing provisioning information. Distribution certificate has not been specified für the „Debug“ platform configuration… Klar hatte ich wie jedes mal vergessen… [Warnung keine Übereinstimmung des Bundle-Bezeichners „“ mit AppID in allen Bereitstellungsprofilen gefunden… Unter Versionsinformationen steht nur CFBundleVersion 1.0.0 drin alle anderen Keys fehlen… OK DProj killen – na klar wenn der sich nacherstellt gibt es nur iOS-Gerät – 64 bit… Also Datei – neu – Geräteübergreifende Anwendung – Speichern unter… Unit hinzufügen Versionsinformation? CFBundleDevelopmentRegion en… -> de FMLocalNotificationPermission -> true 10:44 Uhr <F9>Fehler sind aufgetreten. Missing provisioning information. Distribution certificate has not been specified für the „Debug“ platform configuration… Klar s.o. CFBundleSignature ????->iPhone.Developer <F9>Weitergabe… Pling Package kann nicht installiert werden. (e8008016) CFBundleIdentifier noch setzen… <F9>App da… Jedenfalls das Firemonkey Logo… Bildschirm des iPhones schwarz… PAServer console sagt als letzes „bfd_mach_o_scan_read_syntab_symbol: symbol“_memset_pattern8“ is unsupported ‚indirect‘ reference : settinh to undefined“ aber das lassen wir mal außer acht... OK… nehme ich mal so hin… (Frau bringt mir nen Kaffee… 10:54 Uhr wurde auch mal zeit…) <STRG-F2>… mal ohne debugger aufrufen… Console sagt Unknown Process Boot failure… Und jetzt? OK – Android testen… <F9>Startet Bildschirm Schwarz… Project – Quelltext anzeigen:
Delphi-Quellcode:
Klar habe das Formular mit Drag an Drop reingezogen… Und Delphi hat nur den Pasfile genommen und nicht den *.fmx…
Begin
Application.Initialize; Application.Run; end. Main.Pas löschen und per Hinzufügen... <F9>App Läuft… Natürlich ohne weitere Einstellungen auf Android sofort) Zurück zu iOS… <F9>App läuft – aber funktioniert immer noch nicht… Der Debugger springt aber an die falsche Stelle im Sourceode… Also nochmal im Simulator testen… <F9>Läuft aber ohne Funktion… Ach ja die Versionsinformation sind ja andere… FMLocalNotificationPermission -> true Cool es kommt endlich die Abfrage: „SettingResettingBadgeNumber“ Would Liket o Send You Notifications“ OK! OK Da klappt es… Dumm nur das ich die Abfrage jetzt nicht gedebuggt habe – darum ging es eigentlich … 11:10 Uhr Kurzen Programmierpause 13:00 Uhr Weiter geht es Simulator klappt immer noch…(Leider hat der sich das irgendwo gemerkt und daher kann ich es nicht mehr debuggen. Also nochmal auf dem Device <F9>Unable to mound Developer disk image. (e800000e) Also erst mal Googlen… könnte an der XCode-Version liegen… Oh nein nicht das noch… Hätte ich mein iPhone nicht updaten sollen? OK, vergessen wir mal die TestApp und versuchen es noch mal mit der richtigen Version… <F9>Compile…Link…Weitergeben…Aufrufen… Pling Package kann nicht installiert werden. (e800002d). Kennen wir ja schon also iPhone neu starten… <F9>Weitergabe… Aufrufen…App startet… War das jetzt so schwer? Debugger sagt SValueStr=““… Boh jetzt habe ich echt die Faxen dicke… FMX.Flattform.iOS aus Source ins Projektverzeichniss kopieren…
Delphi-Quellcode:
<F9>Compile… Linken… Weitergeben… Aufrufen… Shit nimmt den alten Source… Aus dem Editor? Komisch
if TOSVersion.Check(8) {and CheckLocalNotificationPermission} then // Und weg damit
13:39 Uhr Alle Files schließen und ein Build machen… (650MB in use, hoffe das Memory reicht noch) 13:42 Uhr Hat gereicht… Ja ein Build dauert 3 Min. Trotz SSD/SSD-Controller und i7 mit > 4GHz, 1GB RAM weg IDE neu starten… <F9>Linken… Weitergeben… Aufrufen… Nöö er weigert sich den Projekt Source zu verwenden… Komisch bei FMX.VirtualKeyboard.ios funktioniert es doch auch… Mal im Projekt File noch oben kopiert… Ahh es funktioniert… Nur der Debugger zeigt den falschen Source-File… Es wird auch Sender.RegisterUserNotificationSettings(Notificati onSettings) aufgerufen… Aber die Abfrage kommt trotzdem nicht. Na Toll: Auf meinem iPhone gibt es schon einen Eintrag für die Benachrichtigungseinstellungen… Steht aber nur auf Banner… Also manuell setzen. Und „schon“ funktioniert es… 14:16 Uhr… Auf zum nächsten Problem... Mavarik |
AW: Ein Tag im Leben eines FMX-App Programmierers...
Du solltest zur Abwechslung mal etwas mit mehr Erfolgsausichten machen um die Stimmung wieder zu heben.
Z.b. den Passierschein A38 besorgen. :thumb: |
AW: Ein Tag im Leben eines FMX-App Programmierers...
Zitat:
Die Abläufe für hardwarenahe Programmierung unter DOS waren irgendwie ähnlich:mrgreen: Gruß K-H |
AW: Ein Tag im Leben eines FMX-App Programmierers...
Zitat:
![]() |
AW: Ein Tag im Leben eines FMX-App Programmierers...
Zitat:
|
AW: Ein Tag im Leben eines FMX-App Programmierers...
bei Z80, dann Intel8051, jetzt Microchip PIC18/24/32 weiß ich bis auf Ethernet&USB auch noch jedes Bit in allen Bytes und kann auch ohne ein OS von "Null" mit einem leerem Projekt anfangen. Am PC ging das nach DOS noch bis WfW311. Ab Win95 und 32Bit war dann am Desktop Schluss mit dem Versuch, alles (voll)verstehen zu wollen/können.
Bei IOS gehen wir radikal vor: es gibt ein paar VM's, welche mit XCode und passenden IOS Geräten die Referenz sind, um neue Sachen zuerst mit XCode SampleProjects aus dem INet zu testen. Erst wenn das geht, kommt der PAserver drauf und wir beginnen ein Delphi Projekt. Auch hier "kopieren" wir stets ein Standardprojekt, was mal "jemand" mit viel Zeit & Mühe sauber vorkonfiguriert hat. Ich selbst wäre auch nicht direkt in der Lage, ohne 2 fertige VMs(eine OSX&XCode plus eine Win7&XE?) schnell mal eine Mobile-Anwendung auf einem IOS Device zu erstellen&testen. Hut ab vor der Geduld und den Willen das mal zu dokumentieren. Trotzdem kopiere ich erstmal weiter unsere VM's mit den Standardprojekten, bevor ich so einen hier beschriebenen StepByStep Versuch mache ;) |
AW: Ein Tag im Leben eines FMX-App Programmierers...
Mein erster Versuch mit Android.
Neue Anwendung erstellen ... nichts verändert ... F9 ... ewig warten, bis das Androidzeugs runtergeladen war ... programm lief nicht (PA-Error 1) ... zugemacht und Tschüß. Das Selbe vorher übrigens im Android Studio ... neues Programm erstellt ... ausführen ... lief ... Button von in GUI gelöscht (in der Anfangsanwendung war ein Button und ein paar Panele) ... ausführen ... *peng* (der Erstellungscode des Buttons blieb zurück, aber weigstens lief es am Anfang wenigstens einmal und das ohne viel einrichten und rumfummeln zu müssen, im Gegensatz zu den Produkten Anderer) Das, was früher mal als "Rapid" (einfach und schnell) beworben war, kann man schon lange vergessen. |
AW: Ein Tag im Leben eines FMX-App Programmierers...
Zitat:
Eigentlich war es so, dass ich immer so gerade rechtzeitig den neuen Compiler bekommen habe um weiter arbeiten zu können. Neben vielen, vielen Verbesserungen besonders auch bei Android... Die 1. Versionen war nicht zu bedienen so langsam... Daher habe ich meine App so schnell gemacht wie es ging mit allen Tricks die mir eingefallen sind... Da FMX@Android viel schneller geworden ist mit XE7,XE8 ist meine App jetzt auf Android superschnell... Aber die Änderungen der Versionen iOS 6->7->8 und Andoid ->5 haben immer viele Änderungen nach sich gezogen und es musste ständig nachgearbeitet werden. Bestes Beispiel: Die Map... 1. Version handgestrickten Wrapper aus dem Beta Forum! (XE2, XE3) 2. Version mit nativer Komponente aus Japan?!?! (XE4 3. Version von TMS... (XE5) 4. Version Google Maps von TMS (XE6, XE7) 5. Version wieder zurück auf nativ XE8 Ich will die Stunden gar nicht zusammenrechnen... Eigentlich wollte ich das nächste Update mit XE7 hochladen... Dann hat der Hotfix mein XE7 gekillt... Das geht zwar jetzt wieder, aber ich habe zu viel auf XE8 schon umgestellt. Doof nur das es zahlreiche Designfehler im XE8 gibt, weswegen die Buttons an den falschen Stellen stehen... Den Fehler hab ich noch nicht gefunden... Also wieder ein Monat dahin... Mavarik |
AW: Ein Tag im Leben eines FMX-App Programmierers...
Ich will jetzt hier keine Stimmung machen, aber nach ausreichendem Testen und Abwägen: Lernt Swift und nehmt XCode - ihr habt mehr Erfolgserlebnisse
|
AW: Ein Tag im Leben eines FMX-App Programmierers...
"aber nach ausreichendem Testen und Abwägen"... genau deshalb nehmen wir doch Delphi mit FMX für Apps!
Der jeweils einmalige (VM) Aufwand bei Updates wird sicher jeweils von einem gemacht, der erstmal Account & Geräte mit AndroidStudio und XCode checkt und dann ein für uns passendes Standardprojekt in Delphi erstellt. Ab jetzt können dann "alle die nur Delphi können" die Sache nutzen. Wenn die "gebastelte" shared GUI 20% im Projektumfang ist, 20% notfalls "irgendwie" angepasster und aufs nötigste begrenzter Plattformcode ist und ich dann 60% echtes CodeShare für 4 Platformen (Win/OSX,IOS,Android) habe, ist das für uns trotz des Aufwandes "bis bei Updates was läuft" ein Zeitgewinn für das was wir dann machen. Selbst kommerziell rechnet sich das, denn für XCode mit ObjC/Swift, AndroidStudio mit Java oder VS.NET mit C# gibt es viele junge dynamische Programmierer und Angebote wie Sand am Meer. Da ist man schnell ersetzbar und muss sich stets großer (Wissens&Angebots)Konkurrenz stellen. Nö, das tuen wir uns nicht an. Deshalb per Delphi-FMX bewusst mit voller Absicht mal was anderes. Über dem Tellerrand von Desktop&Mobile im Embedded-Bereich auf kleinen Microcontrolern herrscht mit C/C++ zwar noch die große Spracheinigkeit, aber bei LowPower 8/16Bit und nur einigen KB Flash & wenig RAM ist es auch eine "Glaubensfrage" welche Prozessortechnologie und dann welcher Derivatehersteller genutzt wird. (z.B. x51, AVR, PIC, ARM, MSP). Das INet ist voll von Zeug & Leuten für AVR&ARM, und genau deshalb nehmen wir es als bewusste Entscheidung nicht. Wir machen alles mit MicroChip PIC-18/24/32 einfach aus Prinzip, auch wenn wir manches selbst anpassen und einpflegen müssen. => deshalb machen wir uns hier das bewusst gewollte Leben mit FMX eben in Selbsthilfe etwas leichter und erträglicher. Wer es anders sieht kann ja VS.NET,XCode,AndroidStuidio oder was auch immer nehmen und sich damit schneller und einfacher seine Erfolgserlebnisse schaffen;) |
AW: Ein Tag im Leben eines FMX-App Programmierers...
Zitat:
Und keine Zeile Sourcecode von einer Plattform auf die andere übernehmen? Obwohl die App auf allen Plattformen das gleiche machen soll?!? Zitat:
Was machst Du mit Android, Windows und Mac? |
AW: Ein Tag im Leben eines FMX-App Programmierers...
Bleibt noch die Frage, ob es wirklich native Entwicklung sein muss. Wir hatten in der Firma Besuch von einem Programmierer aus Ruanda, der für die Regierung dort eine mobile Applikation geschrieben hat, die per Tablet/Fön Landschaften erfasst (Dateneingabe, Photos etc.) Die Anwendung läuft super flüssig, kann auf lokalen Speicher zugreifen (wenn der die Daten doch nicht los wird) und ist sehr sauber bedienbar. Mir ist jetzt nicht aufgefallen, das das eine PHP-Anwendung ist.
Wozu also der Schmunz mit cross plattform Entwicklung? Für Spiele? Zitat:
|
AW: Ein Tag im Leben eines FMX-App Programmierers...
Ich programmiere auch seit 20 Jahren Delphi. Und Swift hat mich jetzt lächerliche 3 Wochen gekostet.Die Erfahrungen mit der Plattform kommen mit der Zeit und man findet auch sehr viel Material im Internet. Genau so mache ich es mit Java und C#, wobei die nicht ganz neu für mich sind.
Außerdem sind die 3 Sprachen nicht gänzlich unterschiedlich zu Delphi, so das es nicht ganz so schwer ist. Man ist mit den IDEs immer aktuell und sie kosten nichts ( VS ggf) . Für den cross platform code nehme ich Elements und erstelle mir eine Bibliothek für alle drei Plattformen. Und sollte mir das alles zu viel werden, suche ich mir entsprechende Programmierer. |
AW: Ein Tag im Leben eines FMX-App Programmierers...
Zitat:
|
AW: Ein Tag im Leben eines FMX-App Programmierers...
Zitat:
Man muss halt (nach einigen Jahren Erfahrung) nicht nur die Idee bewerten, sondern auch die Umsetzung (und ggf. die Haltung des Anbieters). |
AW: Ein Tag im Leben eines FMX-App Programmierers...
Zitat:
Und selbst wenn ihr ausnahmsweise :mrgreen: einen Chef habt, der nicht so doof ist: Jeder ist ersetzbar. Immer. Ach und: Damit verbaut man sich und seiner Firma, zu wachsen, weil: find mal welche, die FMX können. Eure Firma wird auf der Stelle treten und wenn FMX entgültig ein Exot wird, dann ... tja.. finde mal eine Anstellung mit dem Expertenwissen: "Jahrelang auf falsche Pferd FMX gesetzt". Wenn ich bei unseren Bewerbungsgesprächen jemanden mit solchen Kenntnissen finde, schmunzle ich auch immer wieder. Aber vielleicht wollt ihr ja dort alt werden. |
AW: Ein Tag im Leben eines FMX-App Programmierers...
(ganz neben bei: in meiner Firma bin ich der Chef und die Projektpartner mit denen wir zusammenarbeiten setzen auch unabhängig von uns intern weiter auf eine tote Delphi Codebasis)
- ich entscheide nicht wie wir "neu" schnell&einfach etwas lösen könnten, sondern setze eben andere Prioritäten und verkaufe das auch so - es stimmt, es gibt so gut wie keine Delphiprogrammierer mehr am Bewerbermarkt.. das ist nicht schlimm(wir schreiben auch nur noch nachweisbare Erfahrung in OO Programmierung bei Stellen aus, ohne Delphi zu erwähnen), denn eine andere IDE&Sprache ist einem gutem flexiblen Entwickler letztendlich binnen weniger Wochen egal. So wie ich wenn ich wollte auch was direkt mit Java, C# oder ObjC machen könnte, will ich lieber sehen schnell wie ein "neuer" sich in Delphi zurecht findet und was dabei raus kommt, oder ob jemand nur murrt, alles Mist mit XY wäre man schon lange fertig - CrossCode wird überall da sinnvoll, wo die sichere und eventuell sogar funktional zertifizierte lokale Offlineverarbeitung oder Erfassung/Weitergabe von Daten einen Großteil der Funktion ausmacht, und die GUI nur funktional sein muss, also "Optik" keine besondere Rolle spielt - CrossGUI macht für schnelle erste Prototypen sowie schnelle Testerweiterungen von Bestandsprojekten Sinn. Fertig eingerichtet hat man mit XE? wirklich fix auf einen Schlag was für Desktop und Mobile gezaubert und es ist etwas zusehen. (ob es dann wenn es richtig sicher geht, immer noch ein echtes 100% Crossprojekt ist, oder doch mehrere Plattformprojekte mit 20..40% nativ + 80..60% shared Code draus werden, das weiß ich vorher auch nicht) |
AW: Ein Tag im Leben eines FMX-App Programmierers...
Zitat:
|
AW: Ein Tag im Leben eines FMX-App Programmierers...
Zitat:
Das geht in beide Richtungen. btw. Ich habe so gut wie keine IFDEF'S im Code nur für Windows einige... Ansonsten ist mein Code zu 99,9% kompatible zu Windows, OSX, iOS & Android... Höchsten mal wegen unterschiedlicher Font-Größen nach dem Motto:
Delphi-Quellcode:
Mavarik
{$IFDEF iOS}
Button1.Width := 140; {$ELSE} {IFDEF Android} Button1.Width := 160; {$ELSE} Button1.Width := 120; {$ENDIF} {$ENDIF} |
AW: Ein Tag im Leben eines FMX-App Programmierers...
Zitat:
Gibt es einen speziellen Grund, warum Du es hier (dennoch) mit IFDEF's zur Laufzeit löst? |
AW: Ein Tag im Leben eines FMX-App Programmierers...
Vermutlich weil er es schon seit XE2 versucht.
|
AW: Ein Tag im Leben eines FMX-App Programmierers...
Zitat:
Wie auch immer. Mit "Android Tools" aus der XE8-Programmgruppe die benötigten SDK's (nach-) installiert und dann funktionierte auch direkt das erste Kompilat, das korrekt auf das Device (Sony Ultra Z) übertragen und dort ausgeführt wurde. |
AW: Ein Tag im Leben eines FMX-App Programmierers...
Zitat:
In XE8 kann man nichtmal in IDE-Optionen schnell was einstellen (z.B. AutoSpeichern), ohne erstmal Android einrichten zu müssen (oder in meinem Fall das Profil erstmal zu löschen). In XE7 mußte ich auch erstmal das Problem mit dem fehlenden ZipAlign finden, bevor es lief und auf sowas hatte ich jetzt keine Lust. |
AW: Ein Tag im Leben eines FMX-App Programmierers...
Ich kann mich mit Mavariks erstem Post gut identifizieren. Ich habe zuhause und im Büro sieht es ähnlich aus, eine Codebasis aus über 20 Jahren Pascal/Delphi Entwicklung. Vieles ist plattformunabhängig und wenn ein neues Projekt ansteht, auch wenn ich nicht nicht genau den Aufwand abschätzen kann, so habe ich zumindest ein grobes Wissen an was für Code zurückgegriffen werden kann. Das ist jede Menge und selbst wenn ich C "spreche" und C++ bzw. C# ebenso, sowie auch ein gewisses Verständnis für Java hab und trotz meiner Antipathie zu ObjectiveC auch mit XCode erfolge erziehlen kann, so versuche ich fast alles in Delphi umzusetzen. Nicht weil ich zu blöde bin das zu portieren, sondern weil schlichtweg der Aufwand bestehendes für jedes Kackprojekt Wahlweise in Java oder ObjectiveC umzuschreiben. Das aktuelle Dilemma ist, dass Embarcadero einen echt guten Ansatz liefert, aber sobald man ernsthaft eine Anwendung für mehr als Windows erstellen will, ist man mit Problemen konfrontiert die einen zur Weisglut treiben. Seit XE2 ist die IDE immer instabiler geworden und ohne jedes Mal auf eine neue Version upzugraden ist es unmöglich für iOS und Android zu entwickeln.
|
AW: Ein Tag im Leben eines FMX-App Programmierers...
Bin ich froh, damit nicht mein Geld verdienen zu müssen - ehrlich, ich bekäme als beruflicher Programmierer einen Rappel. Wie haltet Ihr das nur tagtäglich aus? Noch ist Cannabis schließlich nicht legal...
|
AW: Ein Tag im Leben eines FMX-App Programmierers...
Zitat:
|
AW: Ein Tag im Leben eines FMX-App Programmierers...
Zitat:
|
AW: Ein Tag im Leben eines FMX-App Programmierers...
Zitat:
Ein ehemaliger Freund hat leider vor einigen Jahren damit angefangen... meinte das sei ja nicht gefährlich und so einen Schwachsinn. Damals hatte er echt was auf dem Kasten, wir haben gemeinsam in Delphi ein Projekt realisiert. Heute ist er nur noch ein Wrack, Frau und Kind weg, raucht einen Joint nach dem anderen, kann nicht mehr klar denken und vergisst alles... |
AW: Ein Tag im Leben eines FMX-App Programmierers...
Du darfst auch einen Radarwarner besitzen, aber das Benutzen ist illegal.
Man darf Kinder schlagen, solange man ihre Würde nicht verletzt. In manchen amerikanischen Bundesstaaten darf man seine Frau schlagen, solange der Stock nicht dicker ist, wie der eigene Daumen. Wenn du Steuern hinterziehst und es sind gaaaaanz Viele, dann ist es weniger schlimm. Manche Gesetze sind ein bissl "komisch". |
AW: Ein Tag im Leben eines FMX-App Programmierers...
Zitat:
![]() |
AW: Ein Tag im Leben eines FMX-App Programmierers...
:thumb:
Ich kenne die Probleme nur zu gut. Was gestern abend lief, muss heute morgen nicht zwangsläufig noch laufen. Wer kennt das Spielchen nicht, dass die FMX Form am nächsten Tag ohne irgendwelche Änderungen völlig verschoben aussieht. Ich habe, nachdem ich die Beiträge hier gelesen habe, nicht auf XE8 aktualisiert. Mit jeder neuen Delphi Version muss ich wieder lernen, wie ich mit den Bugs umzugehen habe. Hatte diesmal echt keinen Bock drauf, dass die App, die ich unter XE7 irgendwie ins laufen gebracht habe, plötzlich nicht mehr läuft, weil Methode/Funktion in Unit irgendwas umgezogen ist oder sich plötzlich irgendwas völlig anders verhält. Blöd nur, dass ein Auftraggeber / Chef genau diese Zeit (die man für das korrigieren / recherchieren braucht) nicht zahlen will. Letztendlich ist Dein Beitrag aber nur ein ungehörter Hilferuf. Es bringt nichts, wütend, sauer zu sein oder mit Abwanderung zu einer anderen Sprache. Es wird sich nichts ändern. Da ich auch nicht für jede Plattform eine eigene Sprache lernen/haben möchte (was für eine uneffektive Idee ist das bitte?), muss ich irgendwie damit leben. Ist wie eine Ehe: Nicht immer super, aber es gibt auch schöne Zeiten ;) PS: Mein nächster Traumjob steht aber fest: Ich möchte im Qualitätsmanagement von Embarcadero arbeiten. Da hat man nicht sehr viel zu tun. |
AW: Ein Tag im Leben eines FMX-App Programmierers...
Zitat:
|
AW: Ein Tag im Leben eines FMX-App Programmierers...
Zitat:
Zitat:
Ich führe meine Änderungen an der RTL seit XE4 mit und ändere jedes mal die neuen Sourcen. Zitat:
Zitat:
1. Ein deutscher Entwickler von EMBT als Schnittstelle (Egal wie gut wir alle englisch sprechen) 2. Viele Viele QC Einträge die nicht gemacht werden weil - zu lästig - man als Antwort nur erhält "as Designed" (Schwachsinn) oder das mehr Infos, ein Beispiel, oder was auch immer benötigt wird. - Der Fehler mitten bei Debuggen gefunden wurde und eigentlich überhaupt nicht klar wie man das a) beschreiben soll b) reproduzieren soll c) als Beispiel liefern soll - klar ich zippe mal eben die 40 Units und schicke sie als Public in das QC. Ich habe mich mit einem Unterhalten: "Das glaube ich nicht, ist hier in keinem Test passiert" - Eh mann ich sehe es auf meinen Bildschirm... "Deinen Fehler kann ich nicht nachvollziehen" - Dann halte Dich doch mal an meine Steps dann wirst Du ihn sehen... "Ist hier nie aufgetreten ich schließe den Fall"... Ich mache daher seit dem JEDES mal ein Video mit Camtasia... Das ist dann nicht weg zu diskutieren... Mavarik :coder: PS.: Zu den Kiffer-Beiträgen sage ich nix... gehört nicht hierher... |
AW: Ein Tag im Leben eines FMX-App Programmierers...
Davon schreibt auch Michael Nickles: Meldet man irgendwohin einen Hard- oder Softwarefehler, kommt mit Sicherheit zurück: "Das hatten wir noch nie."
|
AW: Ein Tag im Leben eines FMX-App Programmierers...
Zitat:
|
AW: Ein Tag im Leben eines FMX-App Programmierers...
Zitat:
|
AW: Ein Tag im Leben eines FMX-App Programmierers...
Wobei Delphi (nicht Pascal) ja vorallem für Datenbankanwendungen ausgelegt war (drum auch Delphi, da
![]() auch wenn es da etwas komisch ist, daß es kein ordentliches Grid gibt. :stupid: |
AW: Ein Tag im Leben eines FMX-App Programmierers...
Es gab mal eine Delphi/Pascal Version für GLSL-Shader (fx-pascal) aber eine "SQL" auf Pascalbasis wäre mir neu.
|
AW: Ein Tag im Leben eines FMX-App Programmierers...
Postgres sieht schon bissl pascallig aus.
|
AW: Ein Tag im Leben eines FMX-App Programmierers...
Zitat:
![]() ![]() Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 03:05 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz