Rad Studio XE5 - Methode wird nicht mehr gefunden

[Rambo]

Hallo

ich arbeite seit einiger Zeit mit dem Rad Studio XE5 und werde langsam verrückt mit dem Teil. Wieder stell ich hier die Frage "was mache ich falsch ?" ich glaub ich bin zu blöde.

Ich weiss gar nicht wie ich es erklären soll das RadStudio XE5 kann sobald ein bestimmter Code in einer Funktion steht diese Funktion nicht mehr auffinden. Beim compilieren läuft zwar alles glatt aber sobald man dann im Objektinspector auf diese Methode zugreifen will kommt eine Fehlermeldung "Implementierung der Methode Button1Click kann nicht gefunden werden".

Er mag anscheinend diesen Zeile Code nicht so ganz, kann das jemand bestätigen ?

void __fastcall TForm1::Button1Click(TObject *Sender)
{
	AnsiString searchStrings[] = {'<','>', '?', '*', ':', '|', '\"', '/', '\\'};
}

[DocShoe]

Fehlt vielleicht vorher irgendwo eine schließende geschweifte Klammer? Oder gibt es die Methoden Deklaration im __published Abschnitt nicht mehr?

[Rambo]

DocShoe schrieb:

Fehlt vielleicht vorher irgendwo eine schließende geschweifte Klammer? Oder gibt es die Methoden Deklaration im __published Abschnitt nicht mehr?

nein fehlt nix, er mag in dieser Schreibweise das hier nicht: '\"' es liegt an dem doppelten Anführungszeichen damit kommt er nicht klar seit RadStudio 5, im RadStudio 4 ging es noch.

so gehts nur finde ich es so umständlicher:

AnsiString searchStrings[9];
	searchStrings[0] = '<';
	searchStrings[1] = '>';
	searchStrings[2] = '?';
	searchStrings[3] = '*';
	searchStrings[4] = ':';
	searchStrings[5] = '|';
	searchStrings[6] = '\"';
	searchStrings[7] = '/';
	searchStrings[8] = '\\';

[Rambo]

in allen 3 Fällen wird die implementierung der Methode nicht mehr gefunden seit RadStudio 5.

void __fastcall TForm1::Button1Click(TObject *Sender)
{
	AnsiString searchStrings[]  = {'\"'};	//Implementierung der Methode Button1Click kann nicht gefunden werden.
	AnsiString searchStrings1[] = {'"'};   	//Implementierung der Methode Button1Click kann nicht gefunden werden.
	AnsiString searchStrings2[] = {"\""};  	//Implementierung der Methode Button1Click kann nicht gefunden werden.
}

[_Stephan_]

Keine Ahnung ob es daran liegt, jedoch was mir aufgefallen ist, ist das ein String mit einem doppeltem Anführungszeichen geschrieben wird, und ein einzelnes Zeichen mit einem einfachen Anführungszeichen.
Ein Versuch ist es Wert.

MfG Stephan

[j.halder]

Hallo,

ohne den XE5-Compiler zu kennen (arbeite selbst mit XE2) vermute ich, dass er beim Casting durcheinander kommt.

Was genau möchtest du damit erstellen?

AnsiString searchStrings[] = {'<','>', '?', '*', ':', '|', '\"', '/', '\\'};

Ein einzelnes AnsiString-Objekt oder ein AnsiString-Array?
Warum die Array-Klammern, wenn nur ein char-Array zugewiesen wird?

M.E. wäre es so richtig:

AnsiString searchStrings = {'<','>', '?', '*', ':', '|', '\"', '/', '\\'};
oder
AnsiString searchStrings = "<>?*:|\"/\\";

Falls es ein AnsiString-Array sein soll, dann eventuell so:

AnsiString searchStrings[9] = {"<",">", "?", "*", ":", "|", "\"", "/", "\\"};

Ohne genaue Größenangabe halte ich ein AnsiString-Array sowieso für ein fragwürdiges Konstrukt. Dafür gibt es Stringlisten (TStringList).

.

[Rambo]

Stephan schrieb:

Keine Ahnung ob es daran liegt, jedoch was mir aufgefallen ist, ist das ein String mit einem doppeltem Anführungszeichen geschrieben wird, und ein einzelnes Zeichen mit einem einfachen Anführungszeichen.
Ein Versuch ist es Wert.MfG Stephan

das kenne ich nur von type char her so.

Es ist doch komisch das im RadStudio 4 diese Probleme nicht gab, es gibt ja auch beim compilieren keine Probleme, sobald man aber über den Objektinspector auf die Methode zugreifen will kann er sie nicht mehr finden.

[Rambo]

j.halder schrieb:

Falls es ein AnsiString-Array sein soll, dann eventuell so:

AnsiString searchStrings[9] = {"<",">", "?", "*", ":", "|", "\"", "/", "\\"};

Ohne genaue Größenangabe halte ich ein AnsiString-Array sowieso für ein fragwürdiges Konstrukt. Dafür gibt es Stringlisten (TStringList).

ja soll ein Array sein, aber auch in diesem Beispiel meckert das RadStudio 5 das die Methode nicht gefunden wird sobald ich den Code dort implementiere:

void __fastcall TForm1::Button1Click(TObject *Sender)
{
   AnsiString searchStrings[9] = {"<",">", "?", "*", ":", "|", "\"", "/", "\\"};	//Implementierung der Methode Button1Click kann nicht gefunden werden.
}

Das war übrigens mein Ursprungscode bevor ich gemerkt hatte daß das RadStudio 5 die Methode nicht mehr findet, hab dann rumgebastelt und kam zu keinem Ergebniss.

[audacia]

Rambo schrieb:

Er mag anscheinend diesen Zeile Code nicht so ganz, kann das jemand bestätigen ?

Nein, weil ich kein RAD Studio XE5 zur Verfügung habe; aber ich kann mir das gut vorstellen. Der Form-Designer verwendet einen arg rudimentären C++-Parser, der sich auch z.B. von zu komplizierten Template-Deklarationen aus dem Tritt bringen läßt. Und der hat wohl irgendein Problem mit in Anführungszeichen stehenden Operatoren. Das Bemerkenswerte ist, daß der Fehler erst in XE5 auftritt. Wahrscheinlich war es ein Seiteneffekt von irgendeinem anderen Bugfix.

Wohlgemerkt ist das kein Compilerproblem. Der Form-Designer, der diese Fehlermeldung verursacht, verwendet nicht den Compiler; und der Compiler übersetzt den Code sicher problemlos, wie du wohl schon festgestellt hast.

Kannst du einen Bugreport bei QC abgeben?

Einstweilen tust du gut daran, den Code in eine separate Klasse auszulagern, was eh sinnvoll ist, weil die Logik deiner Anwendung nicht direkt in der Formularklasse implementiert werden sollte (-> separation of concerns).

[Rambo]

[quote="audacia"]

Rambo schrieb:

Einstweilen tust du gut daran, den Code in eine separate Klasse auszulagern, was eh sinnvoll ist, weil die Logik deiner Anwendung nicht direkt in der Formularklasse implementiert werden sollte (-> separation of concerns).

Ich versuch zumindest den Code in seperaten Funktionen auszulagern, es gibt aber immer Zeiten wo ich schnell bastel und probiere dann aber nie wirklich den Code noch auslager, das sieht natürlich teilweise extrem scheisse aus, geb ich zu, nicht immer gelingt es mir auch eine Klasse für bestimmte Dinge zu bauen, sondern klatsch den Code einfach so dahin, natürlich ist das für die Wiederverwendung in anderen Programmen überhaupt nicht geeignet auch für die Wartung nicht. Naja ich bemüh mich und habe auch immer wieder mal ne Idee den Code besser zu gestalten. das meiste bleibt sowieso hier bei mir aufm Rechner.
Ist für mich halt ein Hobby was mich mein lebenlang begleitet. Kann schon zufrieden sein das ich überhaupt sowas cooles wie programmieren machen kann, es war immer ein Traum und egal wie ich kann ihn etwas ausleben.

Hätte ja mal auch den XE6 probiert aber das Ding läuft nicht auf XP soweit ich da informiert bin. und von meinem OS werd ich nicht weichen. die probleme die dann entstehen würden sollen nicht zu meinen werden, da brauch ich dann nochmal ein ganzes lebenlang um wieder eine angenehme Arbeitsumgebung zu schaffen, die ein sicheres arbeiten ermöglicht, man muss ja auch Vertrauen haben zum OS und all seine Applikationen, ist halt wie in einer Werkstatt die kann man ja auch nicht alle 2 Jahren umräumen und man findet dann nicht wie gewohnt sein Werkzeug am alten Platz vor. So ist das halt bei mir bei euch kann das ja völlig anders sein und wirds sicherlich auch.

Und das mit dem Bugreport bei embarcadero das lass ich mal liebers

[audacia]

Rambo schrieb:

eine angenehme Arbeitsumgebung zu schaffen, die ein sicheres arbeiten ermöglicht

Sicheres Arbeiten? Mit XP und ohne Patches? Stelle ich mir anders vor.

Rambo schrieb:

ist halt wie in einer Werkstatt die kann man ja auch nicht alle 2 Jahren umräumen

Nein, aber nach dreizehn Jahren wäre das höchste Zeit. Aber jeder wie er will.

[Burkhi]

[quote="Rambo"]

Rambo schrieb:

...

Und das mit dem Bugreport bei embarcadero das lass ich mal liebers

Ich hab das mal für dich gemacht

[Rambo]

das ist lieb von dir, danke.

[Burkhi]

Rambo schrieb:

das ist lieb von dir, danke.

Auch wenn man verständlicher erstmal "an die Decke" geht , wenn in späteren IDE- Versionen Sachen nicht mehr funktionieren, die vorher gingen, so sollte man den Hersteller darüber informieren, da er ansonsten ja auch gar nicht weiss, was zu fixen ist. Dazu ist das Quality Center gedacht .

[DocShoe]

Und das wird dann in XE7 gefixt, auf das man kostenpflichtig updaten darf.

[Netzschleicher]

Das ist es was ich so sehr schade finde. Ich habe bis vor einigen Monaten gerne mit dem RAD Studio gearbeitet. Hatte aber zuvor schon beim Übergang vom RAD-Studio 2007 zu XE2 festgestellt, das so einiges verschlimbessert wurde. Und dann zu lesen, das jedes Jahr eine neue noch teurere Version kommt welche scheinbar Fehler von noch älteren Versionen als der 2007er noch mit sich herumschleppen, haben mich dazu bewogen mich vom RAD-Studio weg zu bewegen. Mittleweile liegt es mehr oder weniger als "Programmleiche" auf der Platte und ich beschäftige mich fast nur noch mit Qt und dem Qt-Creator.

[audacia]

Netzschleicher schrieb:

Das [kostenpflichtige Bugfixes] ist es was ich so sehr schade finde.

Ich auch.

Abgesehen von den allgemeinen Qualitätsproblemen geht der Umschwung auf Mobilgeräte und FireMonkey an meinen Bedürfnissen vorbei. Auch wenn der wirtschaftliche Erfolg ihnen wohl recht gibt mit der Mobil-Strategie: leider basiert die Vermarktung auf ideologischer Verklärung. Anstatt darüber zu informieren, was man besser zu machen meint als Qt oder Xamarin, reden sie nur über Native Code on all platforms, und das überzeugt nur Leichtgläubige oder Ahnungslose, da der Delphi-Compiler in bezug auf die Codegenerierung nicht ansatzweise in der Liga von VC++ oder GCC spielt, sondern eher gelegentlich von JavaScript-Interpretern überholt wird [1]. Und der vermeintliche Vorteil von Native Code schwindet vollends dahin, wenn man sich die Zeit damit vertreiben darf, für irgendwelche Android-APIs JNI-Bindings zu erzeugen. Ich hoffe ja für sie, daß die Lösung mit FireMonkey irgendwelche Vorteile gegenüber der Konkurrenz hat; aber dann täten sie gut daran, diese mal in den Mittelpunkt zu stellen.

Ansonsten habe ich die Hoffnung, daß dieser Mobiltelefon-Exkurs finanziell erfolgreich ist, so daß sie sich für die kommenden Versionen erlauben können, die Bugreports abzuarbeiten und wieder die Stammkundschaft zu bedienen. Z.B. ein 32-bit-Compiler auf Clang-Basis wäre nett, oder eine IDE mit zeitgemäßen Refactoring-Features, und die VCL könnte ein bißchen hauptamtliche Pflege gebrauchen. Vielleicht aktualisiere ich dann auch mal wieder. Ich gebe zu, mich noch nicht eingehend mit Qt beschäftigt zu haben, aber ich finde, daß die VCL neben MFC (hoffnungslos antiquiert), WinForms (Stillstand seit 2006) und WPF (latent träge; Steuerelemente sehen immer ein bißchen anders aus als die systemeigenen) immer noch einen guten Stand hat.

[1] Die Seite von Eric Grange mit dem Benchmark ist gerade down, sonst hätte ich einen Link dafür.

[Netzschleicher]

Irgendwie scheint es vielen so zu gehen in Bezug auf RAD Studio. Ich meine, Qt ist mit Sicherheit nicht perfekt, aber was es eben sehr
sympathisch macht ist die Tatsache, das es sehr viel Dokumentation im Netz dafür gibt, es gibt eine Changelist in welcher man
Nachlesen kann was sich von Version zu Version verändert, und es wird wirklich richtig daran gearbeitet, also Bugfix-Releases z.B. .
Ich habe auch schon die Android SDK-Module in den Creator eingebunden und es hat auf Anhieb funktioniert. Auch schön ist es, das
das ganze auch unter Linux mit dem gleichen Look and Feel im Creator funktioniert. Ich werde auf jeden Fall mich viel mehr mit Qt
beschäftigen.