Delphi XE3?

[mkinzler]

Nein funktioniert leider nicht.

Delphi-Quellcode:

type
    MyStringHelper = record helper ( System.SysUtils.TStringHelper) for string
        function Test;
    end;

Zitat:

[dcc32 Fehler] Project1.dpr(7): E2029 ',' oder ':' erwartet, aber '(' gefunden
[dcc32 Fehler] Project1.dpr(7): E2029 ',' oder ')' erwartet, aber '.' gefunden
[dcc32 Fehler] Project1.dpr(7): E2029 ';' erwartet, aber 'FOR' gefunden
[dcc32 Fehler] Project1.dpr(8): E2023 Funktion benötigt Ergebnistyp
[dcc32 Fehler] Project1.dpr(59): E2003 Undeklarierter Bezeichner: 'Test'

[Daniel]

Record-Helper lassen sich im Gegensatz zu Class-Helpern nicht ableiten.

Ich würde auch davon abraten, eine zu große und komplexe Hierarchie in den Helpern - die ja parallel zu den Business-Objekten stehen - etablieren zu wollen. Die Helper selbst sind ja nur Hilfswerkzeuge, die zwar punktuell ungemein praktisch sein können, aber kein Bestandteil des grundsätzlichen Anwendungsdesigns sein sollten.

[TiGü]

Zitat:

Zitat von mkinzler (Beitrag 1181787)

Nein funktioniert leider nicht.

Delphi-Quellcode:

type
    MyStringHelper = record helper ( System.SysUtils.TStringHelper) for string
        function Test;
    end;

Zitat:

[dcc32 Fehler] Project1.dpr(7): E2029 ',' oder ':' erwartet, aber '(' gefunden
[dcc32 Fehler] Project1.dpr(7): E2029 ',' oder ')' erwartet, aber '.' gefunden
[dcc32 Fehler] Project1.dpr(7): E2029 ';' erwartet, aber 'FOR' gefunden
[dcc32 Fehler] Project1.dpr(8): E2023 Funktion benötigt Ergebnistyp
[dcc32 Fehler] Project1.dpr(59): E2003 Undeklarierter Bezeichner: 'Test'

Und wenn du anstatt MyStringHelper es TStringHelper nennst?

Die Abhängigkeit anhand der Uses-Reihenfolge habe ich für Interceptor-Geschichten immer als recht angenehm empfunden.
Warum sollten für Helper andere Regeln gelten als für z.B. für Klassen?

Wie ist das, wenn man sich eigene Typen definiert und davon abhängig eigene Helper?

Delphi-Quellcode:

type
  MyString = System.String

  MyStringHelper = record helper for MyString
    function Test;
  end;

[BUG]

Ist wohl ein ähnliches Problem wie mit der Mehrfachvererbung (welche Methode bei gleichem Namen).
Das mit einer so künstlichen Einschränkung zu umgehen ist aber irgendwie typisch :|

Ableiten ist ja auch keine Lösung, wenn man Helper von verschiedenen Anbietern (und damit Units), benutzen möchte.

[TiGü]

Zitat:

Zitat von BUG (Beitrag 1181790)

Ableiten ist ja auch keine Lösung, wenn man Helper von verschiedenen Anbietern (und damit Units), benutzen möchte.

Wie oft kommt sowas vor?

[mkinzler]

Zitat:

Wie ist das, wenn man sich eigene Typen definiert und davon abhängig eigene Helper?

Dann wird nur die Funktion Test gekannt.

Zitat:

Warum sollten für Helper andere Regeln gelten als für z.B. für Klassen?

Weil es etwas anderes ist. Helper erweitern zur Laufzeit; keine echte Vererbung.

Zitat:

Ist wohl ein ähnliches Problem wie mit der Mehrfachvererbung (welche Methode bei gleichem Namen).

Es gibt gute Gründe, die gegen Mehrfachvererbung sprechen, dieser ist einer davon. Deshalb unterstützen Delphi, Java, C# usw. diese auch nicht.

[Uwe Raabe]

Zitat:

Zitat von TiGü (Beitrag 1181791)

Zitat:

Zitat von BUG (Beitrag 1181790)

Ableiten ist ja auch keine Lösung, wenn man Helper von verschiedenen Anbietern (und damit Units), benutzen möchte.

Wie oft kommt sowas vor?

Kommt schon vor - auch bei eigenen Helpern. Wenn ich bei einem Helper für eine Klasse immer die Vererbungshierarchie der Helper berücksichtigen muss, erhöht das nicht gerade die Modularisierung.

Was aber geht, sind mehrere class helper für unterschiedliche Basisklassen:

Delphi-Quellcode:

type
  TObjectHelper = class helper for TObject
  public
    procedure Foo;
  end;

  TComponentHelper = class helper for TComponent
  public
    procedure Bar;
  end;


procedure TObjectHelper.Foo;
begin
end;

procedure TComponentHelper.Bar;
begin
end;

procedure TForm158.FormCreate(Sender: TObject);
begin
  Foo;
  Bar;
end;

[himitsu]

Oh, hatte gedacht/gehofft, daß man mehrere Helper erstellen kann. :cry: (hab's bisher aber zufällig noch nie benutzt)

Gut, ein Problem ist die Vererbungsgeschichte, also vorrangig das Problem "Was passiert, wenn in 2 Helpern die selbe Methode (Methoden-Name) vorkommt".
Wenn man die Helper voneinander ableitet, wäre das Problem behoben.
(Nja, man hätte es doch stattdessen so implementieren können, daß erst beim Aufruf einer Helpermethode diese Abhängigkeiten geprüft worden wären und hätte dann dort eine Fehlermeldung geworfen)

[Insider2004]

Ich würde Helper überhaupt nicht nehmen. Dafür gibt es Klassen und Vererbung. Helper sollten die absolute Ausnahme bleiben. Schon wie der Name sagt, es sind Helfer. Also für Integer oder Floats z.b.. Ausserdem sind sie eigentlich nur für geschlossene Objekte gedacht, wo man den Quellcode nicht hat/kennt.

[himitsu]

Wieso nicht?

Verteilte Objekte

Man könnte zu Einer Klasse/Type mehrere Methoden-Listen erstellen, vorallem wenn man nicht immer alles braucht.

Gut, man kann weitere Klassen, über Property verschachtelt anbieden, aber da hat der Compiler es schwer (es ist unmöglich) daß der Compilier dieses wegoptimiert,
denn über das vorhandene Property, aber vorallem über das interne Feld (wo z.B. diese Objektinstanz gespeichert werden muß), ist diese Klasse immer bekannt und wird auch immer einkompiliert.

Die Andere Lösung ist eine komplett unabhängig Klasse, welche, wenn man sie nicht verwendet, natürlich nicht einkompiliert wird.
Da der Helper ebenfalls "unabhängig" ist, da die eigentliche Klasse/Typ Diesen nicht kennt, kann hier der Compiler es ebenfalls wegoptimieren.


Genauso wie alles immer vorhanden ist, welches irgendwo in den Initialization-Abschnitten initialisiert wird.
Nutzt man stattdessen den Class-Constructor, dann kann der Compilier diese Klasse weglassen, da die Initialization nicht statisch eingebunden wurde.
PS: Das ist auch einer der Gründe, warum bei der VCL alles so groß wird, im Vergleich zum NonVCL.

[himitsu]

Ich dachte grade, daß man im XE3 die FM-HD/3D-Anwendungen entfernt hatte. :wall:
In XE2 gab es dazu noch 2 Einträge in der Objektgalerie und im Neu-Menü.

Da muß man erstmal draufkommen, daß die jetzt anfangen so Zeugs "unübersichtlich" zu verschachteln.
Firemonkey-Desktop-Anwendungen = ein Wizzard für HD oder 3D

OK, klar ist es nochmals überlegt schon übersichtlicher, also falls in Zukunft mal noch mehr Typen in disen Wizzard reinkommen, aber wenn man erstmal verzweifelt in der Objektgalerie nach dem bekannten HD und 3D sucht und einfach nichts findet.......



Kann man eigentlich problemlos HD und 3D vermischen? (noch nicht ausprobiert)
z.B. für Spiele, wo es ein/mehrere 3D-Level gibt und einige HD-Einstellungsdialoge.

[Darlo]

Zitat:

Zitat von himitsu (Beitrag 1182659)

Kann man eigentlich problemlos HD und 3D vermischen? (noch nicht ausprobiert)

Ja das geht, dafür gibt es den viewport3d auch in HD-Anwendungen.

Gruß

[Peter666]

Ich hab irgendwo in den Ankündigungen gelesen das Embarcadero plant Styles anzubieten und ggf. zu verkaufen. Weiß jemand da etwas genaueres?

Peter

[Uwe Raabe]

Zitat:

Zitat von Peter666 (Beitrag 1182893)

Ich hab irgendwo in den Ankündigungen gelesen das Embarcadero plant Styles anzubieten und ggf. zu verkaufen. Weiß jemand da etwas genaueres?

Peter

Meinst du das FireMonkey Premium Style Pack im aktuellen XE3 Bonus Pack?

[himitsu]

Ich dachte ich hätte auch noch was davon gesehn, daß es direkt von Emba IDE-Styles gibt, womit man sich die IDE sonstwie aussehn lassen kann. :gruebel:

[mkinzler]

das sind aber keine Stile für diie IDE, sondern sind VCL-Styles für das Aussehen der Komponenten.

[himitsu]

Schon Klar.
Dachte nur ich hätte davon mal was gelesen, aber wenn ich nun verzweifelt danach suche......
http://theroadtodelphi.wordpress.com...-theme-editor/ (ist aber nicht von Emba)

nja, zumindestens hier noch was zum Thema
http://theroadtodelphi.wordpress.com...styles-part-i/

[mkinzler]

Diese gibt es aber schon länger

[Peter666]

Ei der Daus, danke für den Link. Das ist ja nur ein zusätzliches Style Pack, ich habe echt gedacht das man sowas wie eine Hand voller Styles anbietet.

[mjustin]

Hallo,

ist die Updatemöglichkeit für Delphi 2009 auf XE3 tatsächlich zeitlich befristet?

Auf der Seite https://store.embarcadero.com/542/purl-dbanner steht aktuell nur:

* Upgrades sind verfügbar für registrierte Besitzer der 2009-XE2-Versionen von RAD Studio, Delphi oder C++Builder; Professional-, Enterprise-, Ultimate- oder Architect-Editionen.
* Versionen vor 2009 berechtigen nicht zum Upgrade und die XE3-Version des Produkts kann nicht aktiviert werden.
* Für Studentenversionen steht kein Upgrade zur Verfügung.

Daher würde ich davon ausgehen, dass es zur Zeit keine Befristung gibt. Oder gibt es eine Quelle die anderes sagt?

[Lemmy]

Hi Michael,

ein paar Seiten weiter vorne...

http://www.delphipraxis.net/167008-d...ml#post1181385

[vagtler]

Zitat:

Zitat von MEissing (Beitrag 1181385)

Upgrade von 2009 nur bis zum Ende des Jahres....

Und danach auch von früheren Versionen... :mrgreen: :angel2:

[himitsu]

Es gibt doch bestimmt irgendwann wieder diese Raubkopiererupgradeaktionen für alle Vorgängerversionen. :stupid:
Ansonsten sind es standardmäßig eben die 3 Vorgängerversionen.

[stahli]

Falls es jemand nicht kennt: http://www.youtube.com/watch?v=f3pwx-FMPIg

Ich finde das schon interessant, allerdings verstehe ich von den anschließenden englischen Gesprächen leider nicht sehr viel...
Ob ein Kauf (und welcher) für mich Sinn machen würde, weiß ich noch nicht recht.
Daher mal ein paar grundsätzliche Fragen:

@Stevie:
Bei 0:51 h ist eine Formular-Eigenschaftsbindung per LiveBinding gezeigt. Früher hast Du ja das DataBinding in der Beziehung noch kritisiert.
Aber so sieht das doch gut aus - oder?
Leider geht es offenbar nicht in die andere Richtung, dass also bei einer Formulargrößenänderung der Wert auch im Edit angepasst wird.
Wenn man nun ein TPerson-Objekt auf das Formular legt und dann die GUI damit verdrahtet, dann sieht das doch schon gut aus- oder?
Zur Laufzéit müsste man dann nur noch die Person-Id zuweisen.

@all - FM2:
Kann man mit FM2 im Grunde auch wie mit der VCL arbeiten und z.B. eigene Komponenten ableiten und auf Drag&Drop reagieren?
Ist eigentlich grundsätzlich denkbar, dass FM sich mal soweit mausert, dass man damit sogar Web-Anwendungen erstellen kann? HTML5 scheint ja vieles zu ermöglichen...

@all - DataSnap:
Wer setzt inzwischen darauf für C/S-Anwendungen?
Wenn man damit gut Objekte zwischen Client und Server übertragen kann (deutlich besser als zu Fuß), dann wäre das vielleicht eine Überlegung wert.

@all - Modellansicht (UML)
Wer nutzt inzwischen die Modellansicht (UML) zur Erstellung von Klassen und Beziehungen?
(Hatte ich hier schon mal gefragt.)

[himitsu]

Wir haben es noch nicht getestet, aber in XE3 sollen endlich die Callbacks nutzbar sein.
(in XE waren sie das nicht wirklich so ganz)

Wenn man keine exotischen Dinge machen will, dann ist es problemlos nutzbar ... nahezu alles, was man in Demos/Tutorials sieht, funktioniert.
(man muß nur beachten, daß einige Tutorialschreiber keine Ahnung haben und gerne mal Speicherlecks einbauen)

[stahli]

Täusche ich mich oder gab es irgendwo ein Bild (oder Hinweis), dass FM2 Bitmap-Skins (z.B. Wood) unterstützt?

[MSo]

geht sicher an deiner Frage vorbei, weil vcl (und vermutlich XE2) , aber
http://theroadtodelphi.wordpress.com...-delphi-forms/

[stahli]

Ist der FinalBuilder nicht mehr dabei?

EDIT:
Der Unterschied zwischen Pro und Ent besteht dann offenbar in:
- DBExpress
- DataSnap
- Intraweb

Ich habe ersthaft überlegt, von XE Prof auf XE3 Ent upzugraden. Der FinalBuilder war dabei ein gewichtiges Argument, das wohl wegfällt!?



@MSo: Vermutlich habe ich das mit dem Wood-Style verwechselt...

[MEissing]

Richtig ist, dass der FinalBuilder bei XE3 nicht dabei ist.

Einfache Lösung: Man nimmt den FinalBuilder von XE2...

(das war jetzt einfach)

[stahli]

Ok, das war einfach. Aber doch irgendwie eigenartig.
Muss man dann XE2 extra komplett installieren und unbedingt VOR XE3?

[Stevie]

Zitat:

Zitat von stahli (Beitrag 1183632)

@Stevie:
Bei 0:51 h ist eine Formular-Eigenschaftsbindung per LiveBinding gezeigt. Früher hast Du ja das DataBinding in der Beziehung noch kritisiert.
Aber so sieht das doch gut aus - oder?
Leider geht es offenbar nicht in die andere Richtung, dass also bei einer Formulargrößenänderung der Wert auch im Edit angepasst wird.
Wenn man nun ein TPerson-Objekt auf das Formular legt und dann die GUI damit verdrahtet, dann sieht das doch schon gut aus- oder?
Zur Laufzeit müsste man dann nur noch die Person-Id zuweisen.

Visual LiveBinding ist schon ganz nett - keine Frage. Dennoch kaschiert das imho nur die unnötig komplexe Architektur der LiveBindings.

Um bei einer Formulargrößenänderung das Edit zu benachrichtigen müsste eine entsprechende Notification gesendet werden (sowohl bei LiveBindings als auch bei DSharp).

Da LiveBindings nun auch im RAD Stil verwaltbar sind, gewinnt man imho garnix dadurch. Wenn ich nämlich das TPerson Objekt auf oder in die Form bringe hab ich wieder Abhängigkeiten auf TPerson und dessen mögliche Abhängigkeiten in der GUI. Der Ansatz, weshalb es die DSharp Bindings primär gibt, ist aber, beides komplett voneinander zu trennen.

[bytecook]

Hab grad gesehen, dass es mittlerweile Hotfix 1-3 zu XE3 gibt...

[RWarnecke]

Zitat:

Zitat von bytecook (Beitrag 1184791)

Hab grad gesehen, dass es mittlerweile Hotfix 1-3 zu XE3 gibt...

Schau mal hier, da ist schon ein Beitrag zu den Hotfixes.

[stahli]

Zitat:

Zitat von stahli (Beitrag 1183932)

Täusche ich mich oder gab es irgendwo ein Bild (oder Hinweis), dass FM2 Bitmap-Skins (z.B. Wood) unterstützt?

Wußt´ich´s doch: http://youtu.be/1X5JKAUte7A?t=29m47s