FireMonkey Sammelthread

[mkinzler]

Deshalb kann so ein Mischprogramm nur auf Windows funktionieren!

[Stevie]

Zitat:

Zitat von mkinzler (Beitrag 1122057)

Deshalb kann so ein Mischprogramm nur auf Windows funktionieren!

Brauch es ja auch nur! Wofür würd man sonst nen VCL Programm bauen... oh halt, es besteht eine gegen Null gehende Chance, dass jemand schon eine VCL Anwendung hat, in die er FMX Elemente einbetten möchte, ohne sein Programm auf FMX umzustellen... /sarcasm off

Aber mal ehrlich, wieso jetzt jeder meint, man würd FireMonkey nur nutzen, um Platform unabhängig zu sein, erschließt sich mir nicht. Nur, weil es das neue UI Framework für cross platform ist, heißt ja nicht, dass man nicht weiter nur für Windows entwickeln darf.

[neo4a]

Zitat:

Zitat von mkinzler (Beitrag 1122057)

Deshalb kann so ein Mischprogramm nur auf Windows funktionieren!

Vööllig neuer Aspekt, Respekt ;)

[Elvis]

Zitat:

Zitat von neo4a (Beitrag 1122060)

Zitat:

Zitat von mkinzler (Beitrag 1122057)

Deshalb kann so ein Mischprogramm nur auf Windows funktionieren!

Vööllig neuer Aspekt, Respekt ;)

Muss gar nicht so komiscj sein, wie es sich liest.
Viele VCL_Anwendungen laufen mit Wine/Crossover auf Linux/OSX, je mehr Hacks aber dazukommen, umso größer die Chance, dass es nciht mehr geht.

(Was natürlich keine Ausrede sein soll, keine native OSX-App zu bauen. Aber das ist eine ganz andere Geschichte...)

[jaenicke]

Zitat:

Zitat von neo4a (Beitrag 1121984)

Was mich besonders stutzig macht, ist die verdächtige Stille aus den Reihen derer, die XE2 schon länger kennen. Hier hätte ich ein begeistertes Feuerwerk an Ideen und Ansätzen erwartet, wie man die neuen Möglichkeiten produktiv nutzt und wie man von den bisherigen migriert.

Oberfläche neu schreiben, Punkt, so sieht es aus was mich angeht. ;-)
Von Zwischenlösungen für einen Mischbetrieb oder sogar Tricks um FireMonkey Elemente auf ein VCL-Formular zu bringen, halte ich persönlich gar nichts. Deshalb habe ich das auch nie probiert und daher zu dem Thema auch nichts geschrieben. ;-)

[Stevie]

Zitat:

Zitat von jaenicke (Beitrag 1122209)

Oberfläche neu schreiben, Punkt, so sieht es aus was mich angeht. ;-)
Von Zwischenlösungen für einen Mischbetrieb oder sogar Tricks um FireMonkey Elemente auf ein VCL-Formular zu bringen, halte ich persönlich gar nichts.

Gönnau! Wir wissen ja alle, dass jeder seine Businesslogik von der GUI trennt und man das mal ebend null komma fix alles umstellt (inklusive aller 3rd party Komponenten).
Außerdem zahlen die Kunden bestimmt für die Zeit um den gleichen Stand auf ner anderen Oberfläche hinzubekommen, was erstmal null Mehrwert darstellt.

[neo4a]

Zitat:

Zitat von jaenicke (Beitrag 1122209)

Oberfläche neu schreiben, Punkt, so sieht es aus was mich angeht. ;-)

Gut, das war jetzt ironisch gemeint, oder?!

Zitat:

Zitat von jaenicke (Beitrag 1122209)

Von Zwischenlösungen für einen Mischbetrieb oder sogar Tricks um FireMonkey Elemente auf ein VCL-Formular zu bringen, halte ich persönlich gar nichts. Deshalb habe ich das auch nie probiert und daher zu dem Thema auch nichts geschrieben. ;-)

Das heißt also, Du hast für solche Punkte wie RichEdit, HTMLView/WebBrowser, Druck-Vorschau, Frames und leicht erweiterbare Grids bereits Lösungen? Um die beneide ich Dich jetzt aber. Da braucht es ja auch gar keine Tricks mehr ;)

[Darlo]

Zitat:

Zitat von Stevie (Beitrag 1122211)

Gönnau! Wir wissen ja alle, dass jeder seine Businesslogik von der GUI trennt und man das mal ebend null komma fix alles umstellt (inklusive aller 3rd party Komponenten).

:thumb:
Da kann ich absolut nix mehr hinzufügen ;-)

[jaenicke]

Zitat:

Zitat von neo4a (Beitrag 1122248)

Zitat:

Zitat von jaenicke (Beitrag 1122209)

Oberfläche neu schreiben, Punkt, so sieht es aus was mich angeht. ;-)

Gut, das war jetzt ironisch gemeint, oder?!

Nein, war es nicht. Deshalb habe ich ja auch geschrieben "was mich angeht". :zwinker:

Was mir da an Komponenten fehlt, das entwickele ich eben oder schaue, ob ich so etwas bald irgendwo bekommen kann. Aber dann lasse ich diese Funktionalität eben aus der FireMonkey Version bis dahin heraus oder löse das anders. Aber ich setze mich jetzt bestimmt nicht wochenlang hin um eine sinnvolle Mischlösung zu basteln. Die Zeit kann ich auch gleich für eine komplette FireMonkey-Lösung verwenden, auch wenn die dann eben nicht ganz so schnell da sein mag...

3rd-Party brauche ich persönlich glücklicherweise so gut wie gar nicht, und wenn, dann habe ich ausschließlich Lösungen im Quelltext, die ich dementsprechend selbst anpassen kann. Lösungen ohne Quelltext würde ich niemals kaufen und nutzen. Ein Beispiel war die TVirtualTreeView, die war eine der ersten, die ich für 64-Bit angepasst hatte, weil ich die relativ häufig nutze.

[Darlo]

Wie sieht es eigentlich mit der Unterstützung von SOAP aus? Ich kann das zwar wunderbar in eine Firemonkey IOS-App einbauen und unter Windows funzt das auch. Sobald man dies nach xCode schiebt ist es jedoch nicht kompilierbar. IdHttp funktioniert dementsprechend auch nicht.

Hat jemand schon erfolgreich einen Webservice an eine iOS-App angebunden?
Gruß

[kaju74]

Ist nicht IP*Works als separater Download für XE2 Kunden dabei:

http://www.nsoftware.com/ipworks/

??

Grß,
Marc

Zitat:

Zitat von Darlo (Beitrag 1122383)

Wie sieht es eigentlich mit der Unterstützung von SOAP aus? Ich kann das zwar wunderbar in eine Firemonkey IOS-App einbauen und unter Windows funzt das auch. Sobald man dies nach xCode schiebt ist es jedoch nicht kompilierbar. IdHttp funktioniert dementsprechend auch nicht.

Hat jemand schon erfolgreich einen Webservice an eine iOS-App angebunden?
Gruß

[neo4a]

Zitat:

Zitat von jaenicke (Beitrag 1122381)

Zitat:

Zitat von neo4a (Beitrag 1122248)

Zitat:

Zitat von jaenicke (Beitrag 1122209)

Oberfläche neu schreiben, Punkt, so sieht es aus was mich angeht. ;-)

Gut, das war jetzt ironisch gemeint, oder?!

Nein, war es nicht. Deshalb habe ich ja auch geschrieben "was mich angeht". :zwinker:

Was mir da an Komponenten fehlt <snip>

... hatte ich ja auch angedeutet. Diese Lösungen kann ich nicht auf FMX-Basis umstellen, obwohl ich - wie Du ja auch - ausschließlich mit Bibliotheken arbeite, die mir im Quelltext vorliegen. Ich sehe diese Dinge wie Du, was mir aber eben nicht weiter hilft. Ein Teufelskreis ;)

Ein weiteres offenes Problem ist für mich die Persistenz (XML, SQLLite etc.), wenn man - wie ich gerade - die Freiheit hat zu wählen und sich bei einem Neuprojekt nicht die Cross-Plattform-Möglichkeit von vornherein verbauen will.

Hier können ja dann durchaus auch Übergangslösungen helfen.

[Darlo]

Zitat:

Zitat von kaju74 (Beitrag 1122390)

Ist nicht IP*Works als separater Download für XE2 Kunden dabei:

http://www.nsoftware.com/ipworks/

??

Grß,
Marc

Zitat:

Zitat von Darlo (Beitrag 1122383)

Wie sieht es eigentlich mit der Unterstützung von SOAP aus? Ich kann das zwar wunderbar in eine Firemonkey IOS-App einbauen und unter Windows funzt das auch. Sobald man dies nach xCode schiebt ist es jedoch nicht kompilierbar. IdHttp funktioniert dementsprechend auch nicht.

Hat jemand schon erfolgreich einen Webservice an eine iOS-App angebunden?
Gruß

Läuft wie ich das sehe nicht unter iOS.

[bytecook]

Zitat:

Zitat von jaenicke (Beitrag 1121977)

Zitat:

Zitat von kaju74 (Beitrag 1121879)

Daraufhin wurde seitens KSDev/Embarcadero in einem ziemlich langen Thread darauf hingewiesen, das es für diese Kunden einen speziellen Rabatt beim Kauf von XE2 geben wird, und das man eine entsprechende EMail erhalten würde.

Ah, ok, dann weiß ich auch worum es dabei eigentlich geht. Denn wie gesagt, logisch fand ich das erst einmal nicht. ;-)

Zitat:

Zitat von kaju74 (Beitrag 1121881)

Nachtrag: In diesem Thread war sogar die Rede von "free", was davon auch immer gemeint war:

Stimmt doch, es gibt es doch ohne Zusatzkosten mit Delphi.

Hallo kaju74 und jaenicke,

ich habe leider den Beitrag erst jetzt gesehen, deswegen nachträglich noch mein Senf dazu:

Wir haben auch das "Lifetime-All-In-One-Wonder" Paket von KSDEV im September gekauft, vier Monate
später war die Firma geschlossen.

Das Paket war wegen der Skalierung nahezu perfekt für uns.
(Anm: Wir entwickeln seit 2007 industrielle Touchapplikationen und waren grade dabei, eine
skalierbare Oberfläche abgeleitet von graphics32.org Komponenten aufzubauen, fanden dann aber KSDEV).

Wir sahen, dass die Firma seit mindestens 2002 aktiv war, der Programmierer und Inhaber Eugene machte
insgesamt einen guten Job, und half zumeist auch schnell mit Bugfixes aus, wenn wir User im Forum
auf einen Bug hinwiesen.

So waren wir der Ansicht, dass wir dieser doch länger im Business befindlichen Firma die Komponenten
mit Source abkaufen können. "Leider" wurde die Firma EMB (zurecht) empfohlen.

Was wir nicht gut finden ist, dass Eugene eben 2 Monate vor dem Verkauf dann die "Lifetime Upgrades"
angeboten hat, anschließend wochenlang nicht erreichbar war und wir in der ersten Jännerwoche von der
IP Übernahme seitens EMB gelesen haben.

EMB hat lediglich das Intellectual Property übernommen und Eugene, den KSDEV Inhaber angestellt.
Dadurch gibt es keinen direkten Rechtsnachfolger, im Schadensfalle gibt es lediglich die Möglichkeit,
sich an den Exinhaber via Zivilrechtsklage zu wenden. Die Firma sitzt oder saß in Russland.

Das ist doch nicht nett, oder?

Dass es verschämt im Frühjahr eine Andeutung im Forum gab, einen Ausgleich für die KSDEV User via
"Gratisprodukt" (etwa Delphi Pro oder so) zu schaffen, und dann den Mantel des Schweigens darüber auszubreiten,
das KSDEV-Forum zu locken, war auch nicht gerade die feine englische Art.

Ich versuche seit März eine Stellungnahme seitens EMB zu erhalten, bin in Kontakt mit der Niederlassung
Maidenhead in UK.

Nun das Positive an der Sache:

Wir haben dann wochenlang ab Januar intern intensives Bugfixing in VGScene betrieben, Komponenten zerlegt und wieder
aufgebaut.

So haben wir viel gelernt. Das ist ja auch was wert.

VGScene haben wir mittlerweile verworfen, den Designer nutzen wir schon unter VGScene nicht, wir haben fast alle unsere
Controls nun von TControl anstatt von TStyleControl abgeleitet, Brushes, Colors, Fonts, etc. lassen sich damit ja ähnlich
wie früher unter der VCL verwenden, das Grundgerüst der Skalierengine reicht für unsere Zwecke völlig.

Letztendlich ist FMX nun ganz passabel integriert, das Produkt muss halt noch etwas reifen, erinnert ein wenig an
TP for Windows nach Delphi 1.0, mal sehen was die nächsten Bugfixes bringen, wünschenswert aus unserer Sicht wäre
eine korrekte Refreshroutine (statt .Repaint muss man zwischendurch Application.HandleMessages aufrufen...)

Gruß,

Peter

[bytecook]

Zitat:

Zitat von kaju74 (Beitrag 1122390)

Ist nicht IP*Works als separater Download für XE2 Kunden dabei:

http://www.nsoftware.com/ipworks/

??

Grß,
Marc

Zitat:

Zitat von Darlo (Beitrag 1122383)

Wie sieht es eigentlich mit der Unterstützung von SOAP aus? Ich kann das zwar wunderbar in eine Firemonkey IOS-App einbauen und unter Windows funzt das auch. Sobald man dies nach xCode schiebt ist es jedoch nicht kompilierbar. IdHttp funktioniert dementsprechend auch nicht.

Hat jemand schon erfolgreich einen Webservice an eine iOS-App angebunden?
Gruß

Ja, IP* muss man sich extra von der "Meine registrierten Downloads" herunterladen...

[BlackSeven]

Mich würde mal interessieren, ob ihr VCL oder FMX für reine Windows-Anwendungsentwicklung bevorzugt.
Ist die VCL überhaupt noch zukunftsfähig / fliegt sie nicht in naher Zukunft raus?

[TiGü]

Zitat:

Zitat von BlackSeven (Beitrag 1159821)

VCL...fliegt sie nicht in naher Zukunft raus?

Wird nicht passieren, dass wäre auf mittelfristige Sicht der Tod der Firma.
Überlege mal, wieviele Millionen von zu pflegenden Altprojekte es da draußen gibt.

[BlackSeven]

Stimmt. Man sägt nicht den Ast ab, auf dem man sitzt.

[mkinzler]

FMX an sich ist eine gute Sache. Es besteht aber noch viel Nachholbedarf dass diese Bibliothek ein Ersatz für die VCL werden kann

[BlackSeven]

Es gibt momentan noch so gut wie keine Komponenten für FMX und "nativ" sieht die Sache auch nicht aus.

Zitat:

Julian Bucknall (DevExpress) said:

By being cross-platform, FireMonkey doesn't have the look-n-feel of native controls, whereas VCL is optimized for native Win32/64...I really do recommend that if you are writing Windows apps, stick to VCL.

[himitsu]

Es gibt bestimmt die Möglichkeit mit einem Skin ein "nativ" wirkendes Aussehen nachzuahmen, aber "nativ" wird es dennoch nicht
und wenn der User sich dann noch einen eigenen Style im Windows eingerichtet hat, dann war's das sowieso.

[mkinzler]

So wird es ja gelöst. Allerdings wird auch der Unterschiede zwischen den verschiedenen Controls der verschiedenen Betriebssysteme etwas angeglichen. Deshalb sieht es nur bedingt "nativ" aus.

[bernau]

Nativ oder nicht nativ. Das hatten wir schon mal. Da kann man sich drüber streiten.

Ich kann gerne auf Nativ verzichten, wenn ich auf ein paar optische Effekte zurückgreifen kann, die mir Nativ nicht bieten kann. Damit wirkt die Applikation etwas frischer. Es gibt einige Applikationen, die nicht auf den Windows-Styles aufsetzen. (Lightroom etc.) Kenne keinen, der sich beschwert hat. Kann nur immer wieder sagen. Daumen hoch für Firemonkey. Der richtige Ansatz. Müssten nur noch ein paar Bugs entfernt werden, damit es wirklich produktiv eingesetzt werden kann.

[stahli]

Welche Einschätzung habt Ihr inzwischen zu FM(2)?

Wer hat schon real damit gearbeitet und für welche Projekte und Plattformen?

[Union]

Ich hab schon real damit gearbeitet. Einen Tetris clone für Windows und iOS und noch ein paar kleinere Apps. Wir wollten damit eine 3D-Visualisierung und BYOD Apps für unsere Logistiksuite erstellen, sind aber auf so viele Probleme, Fehler und Begrenzungen gestossen, dass FM in die Tonne wanderte und VCL + GLScene eingesetzt wird.

[CHackbart]

Hallo,

wir haben hier auch einige Prototypen in Firemonkey entwickelt. Neben diversen kleineren Spielen (z.B. einem Minicraft-Port) haben wir auch große Teile vom DVBViewer, Transedit portiert bzw. diverse Speedtests vorgenommen. Letztere waren der Grund, wieso ich das ganze vorerst auf Eis gelegt habe bzw. wir auf Lazarus überschwenken. Sofern sich nicht wirklich etwas grundlegendes an Firemonkey ändert sehe ich da keine große Zukunft. Es ist ein Unding das eine einfache Liste mit ein paar wenigen Einträgen die CPU Last spürbar beeinflusst. Viel Nerven hat mich auch unser Videotext-Renderer gekostet. Dieser hatte unter OSX fast eine 90% Auslastung produziert und unter Windows war ein Kern auch am Rande seiner maximalen Leistung angelangt. Letzteres konnte ich durch Tricksen beheben. Nun wird die komplette Anzeige in einen eigenen Height*Width*4 Byte großen Framebuffer gezeichnet und nicht via Canvas beschrieben.
Der zweite Screenshot zeigt einen weiteren Prototypen (Test-OSD-Engine). Das ganze ist auch in Punkto Geschwindigkeit nicht wirklich zu gebrauchen. Die gleiche Engine werkelt übrigens in unserer OEM Version vom DVBViewer direkt unter DirectX und produziert da keine messbare Last.

Christian

[jaenicke]

Das gilt für FireMonkey von XE2 oder für das neue von XE3? Denn die Geschwindigkeit ist ja bei XE3 um Größenordnungen besser...
Gerade dein Beispiel mit einer ListBox erinnert mich an XE2, denn da gibt es unter XE3 diese Probleme nicht mehr.

[Union]

Wir werden den Teufel tun und nochmal Zeit verbraten nachdem die Probleme hundertfach in QC eingegeben waren und sich ein Jahr lang nichts getan hat.

[greenmile]

Wir haben ebenfalls einige Projekte realisiert und sind mit FM1 schnell an die Grenzen unter MacOS gestoßen. Es war schlichtweg nicht möglich, eine halbwegs akzeptable Geschwindigkeit (gemessen an einem aktuellen MacBook) zu erreichen. Die Bugs waren einfach nur katastrophal, mehr kann man dazu nicht sagen; es war/ist weniger als eine Alpha Version. Und wir haben uns blutige Nasen beim Kunden geholt!

Mit FM2 wurde das besser: Die Geschwindigkeit wurde akzeptabel, die Bugs weniger und sogar Drag&Drop funktionierte unter Mac. Man bedenke, Mac ist ein System, auf dem sehr oft mit D&D gearbeitet wird und eine Software ohne D&D ist quasi ein No-Go. In FM2 sind aber immer noch einige Hauer drin. Wieso es keine Hint's gibt ist mir ein Rätsel, die Anchors funktionieren in der Praxis nicht wirklich sauber, LiveBindings braucht kein Mensch (funktionieren eh nicht), die Menügeschichte (TMainMenu? MenuBar? Systemmenu irgendwas?) total blödsinnig und die Styles sind nicht durchdacht. Ich muss z.B. für ein Listview den Style verändern, allerdings darf ich ihn anschließend nicht mehr wechseln, sonst sind auch meine Listview Einträge mit weg. Wer hat sich sowas bitte das ausgedacht?

Die Liste der FM Dritthersteller ist übersichtlich, eigentlich befindet sich nur TMS auf der Liste. Die FM Komponenten von denen sind zwar nett, aber Schnickschnack. Wir brauchen wirklich coole Komponenten, nicht nur neue tolle Buttons. Mehr gibt es aber nicht.

Nach anfänglicher Euphorie gibt es kleinere Projekte, aber größeres werden wir nicht realisieren, dafür ist es einfach zu Buggy. Da sich mit XE3 der Status vielleicht zwischen Alpha und Beta befindet, ist es mir einfach zu heikel, darauf zu setzen. Zumal iOS aus der ersten FM Version wieder rausgeflogen ist, also wird demnächst wieder ein iOS kommen und wird dann sicherlich als die Wiedergeburt gefeiert; zu einem ordentlichen Preis. Dass Android immer noch nicht drin ist ... Nun ja, peinlich würde ich sagen.

Alles in allem: Ich hatte wirklich große Hoffnung in XE/XE2/XE3 und dem Wechseln zu Embar gesteckt, aber das Ergebnis ist enttäuschend. Und das wird sich mit Sicherheit auch nicht in den nächsten Monaten, 1-2 Jahren ändern!

[Bentissimo]

Bei der Ankündigung von XE2 wurde ich auch hellhörig ob der potentiellen Unterstützung von iOS und MacOS. :-D

Aufgrund dieser für Delphi völlig neuen Welt wollte ich aber noch abwarten, wie sich die Lage entwickelt. :shock:

Wie sich inzwischen rausgestellt hat und vielfach beschrieben wurde, leider zurecht. :pale:

So gerne ich in Richtung Apple OS gehen würde, so gefährlich (und sogar fahrlässig) wäre das zumindest noch zur Zeit mit FireMonkey. :?

Ich neige inzwischen deutlich zu RemObjects Oxygene und der bald neu erscheinenden Unterstützung in Form von "Nougat". :P

Bin sehr gespannt wie sich das anfühlen wird...

Zudem gibts da derzeit ein Einführungsangebot: 499$ für alle drei Oxygene Plattformen (.net, Java/Android und eben bald iOS/MacOS).

Scheint mir zumindest Stand heute der bessere Weg zu sein.

[stahli]

Ich will man temporär eine Statusbar einblenden (nicht meckern, es ist eine Spielerei) und ein Label für einen Zähler nutzen.
Die Aktualisierung des Formulars erfolgt erst nach der Prozedur.

Wie kann man zwisdchendurch refreshen? Ich dachte, FM wäre da direkter als die VCL...

Delphi-Quellcode:

procedure TFormPersonsGrid.Insert10000;
var
  I: Integer;
  DS: TSQLDataSet;
  Id: Integer;
  FieldName: string;
begin
  beep;
  StatusBar.Visible := True;
  StatusBar.Repaint;
//  Self.Update; ???
  for I := 0 to 1000 - 1 do
  begin
    LabelStatus.Text := Format('%d', [I]);
    BlaBlaBla;
  end;
//  StatusBar.Visible := False;
  beep;
  FillGridData;
end;

[stahli]

Ich spiele gerade mal an einem kleinen DataBinding-Framework herum.
Ich kann u.a. schon mit einer Checkbox Edit1.Enabled umschalten.
Das funktioniert "funktional" auch wie erwartet, aber die Controls werden nicht neu gezeichnet bzw. erst wenn ich das Formular minimiere und wieder herstelle.

Ein ausdrückliches Repaint hilft auch nicht weiter.

Delphi-Quellcode:

procedure TssfCtrl.set_PropText(const Value: string);
begin
  if Assigned(BindObject) then
  begin
    SetPropValue(BindObject, PropName, Value);
//    if (BindObject is TControl) then
//      (BindObject as TControl).Repaint; // hilft nicht
  end;
end;

Weiß jemand auf Anhieb, wo es mangelt? Vermutlich muss noch das Formular den Auftrag erhalten, sich neu zu zeichnen.
Invalidate - wie in der VCL - gibt es ja nicht.

[stahli]

Ein etwas älteres aber interessantes Beispiel für eine GUI unter FMX: http://www.youtube.com/watch?v=AmkEO8QBsBU

Attraktiv ist das schon und man sollte FMX nicht zu früh verteufeln...

[bytecook]

Haben unsere erste Software unter FM2 fertig, diese läuft ganz nett. Habe als "Styles - Lernvorlage" die FM TMS Komponenten genommen,
(Unter KSDEV/FM hab ich Styles von Hause aus vermieden) dann größtenteils unsere eigenen Komponenten mit dementsprechender Komplexität
(Dynamische Subkomponenten, etc) entwickelt.

Die Software läuft unter Windows 7 /8, wir verwenden seit 2007 Touchsysteme im industriellen Umfeld. Die Styles waren anfangs etwas tricky,
neue zu erstellen ist mittlerweile sehr simpel.(Nehme dazu Notepad)

Halte aber fest:

Unsere XE3 Frontend Anwendungen laufen zur Zeit ausschließlich unter Windows 7/8, wechseln keine Styles.

Auch nicht zu vergessen:

Wer keine Styles mag, und schon Komponenten unter VCL entwickelt hat, der kann nach wie in der VCl Brushes/Farben, etc publishen, auch wenn
das manchmal ein Stilbruch sein mag. Besser aber, als immer wieder die Ereignis-OnPaint Methoden für jedes Teil umschreiben zu müssen.

Wenn man aber ein gewisses Maß an SI (CI für SW) erreichen will, dann ist es immer nett, Styles zu verwenden. Ich halte jedoch bei
manchen Komponenten nicht dogmatisch an den Styles fest ...

[stahli]

Kann man mal was sehen (Screenshots/ Demovideo o.ä.)?
Wie bringst Du Daten in die GUI?
Bindung über FindStyleRessource (oder wie das hieß)?

Für was steht: SI (CI für SW) ?

[Sir Rufo]

CI = Corporate Identity
SI = Software Identity

;)

[bytecook]

Zitat:

Zitat von stahli (Beitrag 1198389)

Kann man mal was sehen (Screenshots/ Demovideo o.ä.)?
Wie bringst Du Daten in die GUI?
Bindung über FindStyleRessource (oder wie das hieß)?

Für was steht: SI (CI für SW) ?

Screenshots muss ich erst machen, anbei aber der Link zu den Anleitungen
In der Anleitung sind einige Screenshots drinnen...

Screenshots meiner bereits fertigen FM2 Programme in den Manuals

SG6 Manual 'Draft'
SCD Usermanual

Zu den Daten: Habe meine eigene Stream Datenversorgung, Properties werden direkt beschickt
und kommen ohnen Bindings aus.
(Viele Komponenten werden erst zur Laufzeit bei Bedarf erzeugt)

FindStyleResources ist innerhalb meiner Komponenten gekapselt und wird nur zum
Subcomponent-Fetchen verwendet

Delphi-Quellcode:

(******************************************************************************)
function TSTBFMXBasePanel.GetRadioButton (Value : String) : TSTBFMXRadioButton;

  var fmxobj : TFMXObject;

  begin
    fmxobj := FindStyleResource(Value);
    if assigned(fmxobj) then
      if fmxobj is TSTBFMXRadioButton then Result := fmxobj as TSTBFMXRadioButton
                                      else Result := nil;
  end;
(******************************************************************************)

Ja, SI und CI sind schon erklärt :)


Grüße,

Peter

[bytecook]

Zitat:

Zitat von stahli (Beitrag 1196664)

Ich spiele gerade mal an einem kleinen DataBinding-Framework herum.
Ich kann u.a. schon mit einer Checkbox Edit1.Enabled umschalten.
Das funktioniert "funktional" auch wie erwartet, aber die Controls werden nicht neu gezeichnet bzw. erst wenn ich das Formular minimiere und wieder herstelle.

Ein ausdrückliches Repaint hilft auch nicht weiter.

Delphi-Quellcode:

procedure TssfCtrl.set_PropText(const Value: string);
begin
  if Assigned(BindObject) then
  begin
    SetPropValue(BindObject, PropName, Value);
//    if (BindObject is TControl) then
//      (BindObject as TControl).Repaint; // hilft nicht
  end;
end;

Weiß jemand auf Anhieb, wo es mangelt? Vermutlich muss noch das Formular den Auftrag erhalten, sich neu zu zeichnen.
Invalidate - wie in der VCL - gibt es ja nicht.

Wie siehts mit einem .Realign Aufruf der Komponente aus?
Oder verwende mal BeginUpdate/Dein Code/EndUpdate ...

[stahli]

Ich habe noch ein wenig probiert und noch ein paar Punkte herausbekommen - aber keine Lösung gefunden.

Wenn ich aus meinem Framework heraus ein Control neu zeichnen lasse wird bis zum Formular hoch das entsprechende Rect als ungültig deklariert.
Allerdings erreiche ich eine wirkliche Neuzeichnung des Formulars erst durch eine Größenänderung des Formulars.

Im Formular reicht ein Timer, der ein Invalidate ausführt.

Delphi-Quellcode:

procedure TForm1.Timer1Timer(Sender: TObject);
begin
  Invalidate;
end;

In meinem Framework ermittle ich das korrekte Form, kann aber kein Neuzeichnen veranlassen.
Mit EndUpdate und ReCreate klappt das aber das Formular wird kurz ausgeblendet und neu gezeichnet.

Delphi-Quellcode:

procedure TssfCtrl.RefreshControl(Control: TControl);
var
  P: TFmxObject;
begin
  if not Assigned(Control) then
    Exit;
  // Control.BeginUpdate;
  // Control.Repaint;
  // Control.EndUpdate;
  // Exit;
  P := Control.Parent;
  while Assigned(P.Parent) do
    P := P.Parent;
  if (P is TForm) then
  begin
    // public Methoden:
    // (P as TForm).Invalidate;  // nix
    //
    // (P as TForm).BeginUpdate;
    // (P as TForm).EndUpdate;   // flackert
    //
    // protected Methoden:
    // TCrackForm(P).Realign;      // nix
    // TCrackForm(P).Resize;       // nix
    // TCrackForm(P).Recreate;     // flackert
    // TCrackForm(P).Updating;     // nix
    // TCrackForm(P).Updated;      // nix
    // TCrackForm(P).UpdateStyle;  // nix
    // TCrackForm(P).ResizeHandle; // nix
  end;
end;

Das Zeichnen meines eigentlichen Controls kann ich an der Stelle sogar weg lassen (wird schon durch die Eigenschaftsänderung veranlasst).

Offenbar kriegt der Mainthread wohl irgendwie von der Änderung nichts mit (obwohl ich gar nicht wirklich sagen kann in welchem Prozess die Änderung gezeichnet wird).
In dem Zusammenhang stellt sich natürlich auch noch die Frage, wie das mit dem Repaint dann unter Mac bzw. auf den mobilen Plattformen laufen würde.

Falls jemand mit meinem Baustellenprojekt (XE3) mal herumspielen will könnte ich das mal per Mail schicken.

[stahli]

Hmm, ich komme an der Stelle nicht wirklich weiter. Sehr rätselhaft...

Also ich bastle ein Databinding-Framework (mal sehen, was draus wird, erst mal ist es auf jeden Fall interessant).
Wenn ich aus einem Edit eine Änderung an die Datenschicht schicke wird die GUI danach über die Änderung informiert und die GUI-Controls werden veranlasst, sich mit den neuen Daten zu zeichnen.

Das funktioniert auch - nur wird die Änderung nicht sichtbar bis ich die Formulargrößere ändere oder z.B. in einem Timer Invalidate für das Formular ausführe.
Der richtige Wert liegt aber dann "nachweislich" ja in den Controls schon vor.

Das komische: Wenn ich aus einem Timer heraus z.B. TimeToStr(Now) in die Datenschicht schicke (anstatt bei einer Texteingabe im Edit) werden die an das Feld gebundenen Controls immer korrekt gezeichnet (bzw. der entsprechende Bereich auf dem Formular). Die anderen Controls aber wiederum nicht.

Wenn bei überschneidenen Controls das andere Control neu gezeichnet wird (z.B. wenn ein Edit focusiert wird), sieht man von dem nicht aktualisierten Control einige Pixel, die jetzt aktualisiert wurden.
Also wurde die Änderung auf dem Screen noch nicht aktualisiert, im Puffer sind die aber schon vorhanden.

Wenn jemand sich in dem Bereich mal beschäftigt, dann wäre ich für einen Tipp dankbar.
(Kann auch gern den aktuellen Stand schicken.)