Fehler: Falscher Variablentyp

[ByTheTime]

Also, (ihr quetscht mich ja ganz schön aus ), mit "Es will nicht" habe ich das Programm gemeint. Aber ich habe auch eine erfreuliche Nachricht. Ich habe erst gedacht, der Fehler tritt auf, wenn ich Excel öffne, da ich erst an ein Problem mit der Excel-Variable gedacht habe. Aber es war mal wieder ganz simpel, ich habe den Fehler durch "ausklammern" gefunden (mit {} immer den Code ausgeklammert, der es sicher nicht ist bis ich ganz nahe an der Fehlerquelle bin ).

Delphi-Quellcode:

Excel.Cells[4, 4].Value := EdName; //Was stimmt da wohl nicht?!

--> Excel.Cells[4, ].Value := EdName.Text;

Die Fehlermeldung hat mich etwas verwirrt, weil ich sie nicht mit dem Fehler in Verbindung bringen konnte... Hätte eher sowas erwartet wie 'Inkompitable Typen...'

Aber danke für den "Nachhilfeunterricht" in Sachen IDE

[Sir Rufo]

Weil das Ausklammern so umständlich ist, gibt es den Debugger.

Der Debugger funktioniert aber nur, wenn in den Projekt-Optionen "Debug" eingestellt ist.

Dann kann man Halte-Punkte setzen und komplett Schritt für Schritt durch das Programm gehen.

[schierl]

Hallo an alle Wissenden,

gibt es zu diesem Thema schon eine Lösung?
Ich habe das selbe Problem mit Delphi XE2, von D2005 bis zu XE hat es immer ohne Probleme geklappt!

In meinen Excel Exporten verwende ich folgende Zeile

...
ExcelWorksheet1.Cells.Item[i,1].value := q_crack_bei_km['ppa_Verfahren'];
...

Wobei ExcelWorksheet1.Cells.Item[i,1].value ein OleVariant,
q_crack_bei_km ein Dataset
und q_crack_bei_km['ppa_Verfahren'] ein TStringField ist.

Wenn ich die Zeile wie folgt abändere

...
ExcelWorksheet1.Cells.Item[i,1].value := string(q_crack_bei_km['ppa_Verfahren']);
...

oder

...
ExcelWorksheet1.Cells.Item[i,1].value := q_crack_bei_kmppa_Verfahren.Value;
...

funktioniert es wieder ohne Problem!
Bei den anderen Typen wie TIntegerField oder TFloatField tritt dieser Effekt nicht auf!
Genauso wenn ich es mit Delphi XE compiliere tritt der Fehler auch nicht auf.
Ich würde mir aber gerne ersparen alle TStringField ab jetzt zu casten!
Sollte ich noch etwas vergessen haben oder mehr Source Notwendig sein bitte bescheid geben!

Danke schon mal im Voraus

Johann

[himitsu]

Zitat:

ExcelWorksheet1.Cells.Item[i,1].value := string(q_crack_bei_km['ppa_Verfahren']);

Das Ziel ist ja ein Variant/OleVariant und das andere ein Objekt.
Grundsätzlich solltest du einfach immer davon ausgehn, daß es nicht einfach so eine Konvertierunbg von Ojekt in was Anderes gibt.

Vor einer Weile wurde zwar TObject.ToString eingeführt, aber dieses wurde noch nahezu nirgendwo verwendet/überschrieben, denn dieses muß für jeden Objekttyp einzeln implementiert werden, da es von alleine nicht weiß, wie der Inhalt dieses Objektes in ein String umgewandelt werden könnte.
Somit ist es auch nicht sicher, was die String(...)-Konvertierung zurückgibt, da sie am Ende "hoffentlich" auf ToString gemäppt wird.
(Sollte hier direkt der Objektzeiger in einen Stringzeiger gecastet werden, dann hast du ein großes Problem)

Wenn es sich bei dir um TField-Nachfahren handelt, solltest du besser immer .Value verwenden, oder notfalls einfach immer .AsString (was ja auch bei Integer und Co. ginge).

[schierl]

Hallo himitsu,

Zitat:

Grundsätzlich solltest du einfach immer davon ausgehn, daß es nicht einfach so eine Konvertierunbg von Ojekt in was Anderes gibt.

du hast natürlich vollkommen recht, aber der Code denn ich verwende funktioniert schon seit Jahren so (Delphi 7 bis XE).
Ich bin gerade dabei alle meine Programme auf Delphi XE2 umzustellen und dabei über das Problem gestolpert.
Ich kann mir nicht vorstellen, daß eine Konvertierung die es schon seit Jahren gibt, auf einmal nicht mehr geht.
Das von dir zitierte Beispiel wäre auch der schlechteste Fall um das Problem zu beheben.
Änderung zwei ist mein Favorit derzeit, gefällt mir aber so nicht.
Der Aufruf DataSet['Variablenname'] ist einfach flexibler als der Aufruf DataSetVariablenname.Value. In einigen Fällen
ermitlle ich erst zur Laufzeit wie die Variable heist und exportiere sie dann nach Excel. Und wie schon erwähnt funktioniert
das mit allen Typen ausser mit TStringField in der Kompination mit TDataset.

[p80286]

Zitat von schierl:

Ich kann mir nicht vorstellen, daß eine Konvertierung die es schon seit Jahren gibt, auf einmal nicht mehr geht.

So wenig Phantasie?
Auch wenn ich Deine Emotionen verstehen kann, Du solltest zunächst einmal das Verhalten des Compilers akzeptieren und bei Gelegenheit Deine Schlüsse daraus ziehen.

Gruß
K-H

[schierl]

Zitat von p80286:

Zitat von schierl:

Ich kann mir nicht vorstellen, daß eine Konvertierung die es schon seit Jahren gibt, auf einmal nicht mehr geht.

So wenig Phantasie?
Auch wenn ich Deine Emotionen verstehen kann, Du solltest zunächst einmal das Verhalten des Compilers akzeptieren und bei Gelegenheit Deine Schlüsse daraus ziehen.

Das dürfte woll stimmen denn ich verstehe diese/n Antwort/Kommentar leider nicht!
Was hat das mit dem Thema zu tun? Oder versteht man darunter die Aussage 'It's not a bug, it's a feature!'
Ich sehe das ganze eigentlich ziemlich Emotionslos sondern eher so das es sicher viele Leute gibt,
die mehr wissen und verstehen als ich.

Gruß

Johann

[Iwo Asnet]

Zitat von schierl:

...
Wobei ExcelWorksheet1.Cells.Item[i,1].value ein OleVariant,
q_crack_bei_km ein Dataset
und q_crack_bei_km['ppa_Verfahren'] ein TStringField ist.

Der letzte Satz ist nicht korrekt: Es muss heißen

Zitat von Der Klugsch...:

und q_crack_bei_km['ppa_Verfahren'] ein TStringField Variant ist.

Neuerdings verwendet Delphi WideString, wenn irgendwo 'String' steht. Ich vermute, das steht in direktem Zusammenhang. Denn so gesehen ist an deinem Code nichts verwerfliches festzustellen.

Die Sache mit den Emotionen und der fehlenden Phantasie verstehe ich auch nicht so ganz.

[himitsu]

[QUOTE=Iwo Asnet;1170328]Der letzte Satz ist nicht korrekt: Es muss heißen

Zitat von Der Klugsch...:

und q_crack_bei_km['ppa_Verfahren'] ein TStringField Variant ist.

Wobei das eine komplett andere Aussage darstellt ... meine Antwort war natürlich uf das TStringField bezogen.

Zitat von Iwo Asnet:

Neuerdings verwendet Delphi WideString, wenn irgendwo 'String' steht. Ich vermute, das steht in direktem Zusammenhang. Denn so gesehen ist an deinem Code nichts verwerfliches festzustellen.

Seit Delphi 2009 ist String (nicht der ShortString) ein Alias für den UnicodeString und davor zeigte er auf den AnsiString.
Der WideString ist ein komplett eigenständiger Stringtyp.

LongString = AnsiString und UnicodeString sind quasi aufgemotzte dynamische Arrays of AnsiChar/WideChar
ShortString = ShortString und String[123] sind Records mit einem statischen Array of AnsiChar
WideString = ein Wraper für OleString (SysAllocString und Freunde)

[schierl]

Danke an den Iwo Asnet für die Richtigstellung, bei dem Versuch soviel Information wie möglich zu geben,
habe ich mich dann ver(w)irrt und entschuldige mich dafür!