Entwickler-Ecke
Delphi Language (Object-Pascal) / CLX - D2010 -> Excel, anders als D7 -> Excel?
Stecky2000 - So 21.03.10 19:22
Titel: D2010 -> Excel, anders als D7 -> Excel?
Hi Ihr..;-)
Ich hab schon die Boardsuche genutzt, finde tausend Beiträge zum Thema Delphi -> Excel, aber keinen der meine Frage beantwortet.
Eigentlich sind es mehrere Fragen, ich würde mich aber zunächst mit folgender begnügen:
Ich habe eine Programmzeile aus Delphi 7 die sieht so aus:
Delphi-Quelltext
1:
| Excel.Cells[Zeile, Spalte] := '-'; |
Unter Delphi 7 macht sie wohl was?
Sie trägt ein Minuszeichen in eine Excelvorlage ein.
Das ist so gewollt, nur, was macht sie unter Delphi 2010?
Sie trägt die Zahl "45" (Fünfundvierzig) in die Zelle ein?!
Verändere ich das '-' zu '--' dann trägt er auch genau zwei Minuszeichen ein.
Woran liegt das und wie kann ich das machen, dass wieder ein Minuszeichen eingetragen wird und keine 45.
EDIT:
Ich habe mittlerweile rausgefunden, dass 45 der ASCII-Code für das Minuszeichen ist.
Deshalb habe ich folgendes versucht:
Delphi-Quelltext
1: 2:
| MyChar := Chr(45); Excel.Cells[Zeile, Spalte] := MyChar; |
Leider mit gleichem Ergebnis. :(
Die anderen Fragen, einfach um es zu wissen:
In D7 wurde geschrieben
Delphi-Quelltext
1:
| Excel.Cells[Zeile, Spalte].value := 'irgendwas'; |
oder
Delphi-Quelltext
1:
| Excel.Cells[Zeile, Spalte].Text:= 'irgendwas'; |
In Delphi 2010 sagt er zu .value oder .Text das wären undeklarierte Bezeichner.
Wenn ich sie einfach weg lasse, funktioniert alles ganz normal.
Ich habe mich nur nicht getraut das .select weg zu lassen.
Vielleicht könnt Ihr mir etwas dazu vermitteln.
BenBE - Mo 22.03.10 00:45
Versuche mal folgendes:
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7:
| var S: String; SV: Variant; begin S := '-'; SV := S; Excel.Cells[Zeile, Spalte] := SV; |
Da zwischen D7 und D2010 die Behandlung von Strings geändert wurde (
String=
AnsiString unter D7,
WideString unter D2010) kann ich mir gut vorstellen, dass es bei der Behandlung von
String-Literalen in OLE-Variants, wie sie für den Zugriff auf Excel verwendet werden ein paar Bugs eingebaut haben.
Alternativ kannst Du mal schauen, wie sich ein explizites
#0 am Ende des Strings (
'-'#0) auswirkt.
Vergleiche zudem mal den ASM-Source, der von den verschiedenen Varianten unter D7 und D2010 erzeugt wird, bzw. poste ihn hier für ne kurze Analyse.
Stecky2000 - Mo 22.03.10 07:03
Moderiert von
Narses: Komplett-Zitat des letzten Beitrags entfernt.
Erstmal, vielen Dank für die Antwort!
Vielleicht liege ich falsch oder erwarte einfach zu viel, aber mir kommt es in letzter zeit vor, als bekommt man (ich) kaum Antworten auf Posts/Fragen.
Von daher, wirklich vielen Dank für die Antwort.
Also, ich werde das natürlich sofort versuchen, sobald ich zu Hause bin und an mein Delphi kann.
Eine weitere Frage hierzu: Was ist ein "ASM-Source" und wie komme ich an diesen?
Ich muss es immer wieder wiederholen, ich bin kein Programmierer, was mir bei manchen Fragen etwas peinlich ist, aber ich versuche es gerne.
EDIT: Ich bin zur Zeit etwas unzufrieden mit Delphi 2010.
Ich denke schon mind. 2 Fehler gefunden zu haben, eben hier diesen im Umgang mit Excel und, naja, ist zwar nicht wirklich Delphi, in Rave.
Desweiteren bin ich mit der Hilfefunktion recht unzufrieden. Im Gegensatz zu den alten Versionen hilft mir die Hilfe unter Delphi 2010 bisher überhaupt nicht.
Man muss ständig darauf achten dass man nicht gerade die Hilfe für c++ liest und Beispiele habe ich gar keine mehr gesehen.
Ich greife ständig wieder auf die Hilfe von D7 zurück.
BenBE - Mo 22.03.10 07:20
Den ASM-Source findest Du, wenn Du während des Debuggens der Routine (Breakpoint setzen) auf Ansicht --> Debug-Fenster --> CPU-Fenster zugreifst.
P.S.: Bzgl. der Antworten: Jain, der Anteil an Posts, die man auf Grund mancher Autoren ignoriert (ich nenne jetzt keine Namen) hat lediglich zugenommen. Bestimmte Personen lese ich nur noch, wenn mir langweilig ist.
Stecky2000 - Mo 22.03.10 07:42
Moderiert von
Narses: Komplett-Zitat des letzten Beitrags entfernt.
Ich hoffe, ich bin nicht langweilig, weil meine Probleme für Profies wie dich Peanuts sind :)
Nochmal Danke.
Normalerweise bekomme ich immer Hilfe, wenn man (ich) sich an bestimmte Vorgehensweisen hält
- Boardsuche ausgiebig nutzen,
- googlen,
- Problem verständlich darstellen,
- Code-Schnipsel beifügen,
- zeigen dass man sich nicht die Arbeit machen lassen will sondern selbst was tun möchte.
Ich schaue auch viel in anderen Foren, allerdings vermeide ich es ein Problem zeitgleich in zwei Foren zu posten.
Das ist nicht gerne gesehen, was ich auch verstehe.
EDIT: Wie geht man eigentlich damit um, wenn das tatsächlich ein fehler in Delphi ist? Würde Embarcadero überhaupt ernst nehmen wenn ich denen das schreibe?
Manchmal bekommt man eben doch keine Antwort, was für Leute wie mich frustrierend ist.
Ich kann zwar einigermaßen das programmieren was ich brauche, doch um analytisch heraus zu finden, warum z. B. D7 anders arbeitet als D2010 und dann die entsprechende Lösung zu finden, dafür reicht es nicht immer.
BenBE - Mo 22.03.10 17:57
Stecky2000 hat folgendes geschrieben : |
| EDIT: Wie geht man eigentlich damit um, wenn das tatsächlich ein fehler in Delphi ist? Würde Embarcadero überhaupt ernst nehmen wenn ich denen das schreibe? |
Es gibt bei
Borland Inprise CodeGear Embarcadero einen Bugtracker, wo solche Reports gesammelt werden. Wenn man es schafft, den Fehler dort zu posten und verständlich darzulegen, dass es sich dabei um nen Fehler am Compiler handelt, wird da meist was gemacht.
Wo aber oftmals nichts gemacht wird, sind "Fehler for Compatibility", wie es so schön einen in TForm.AlphaBlend einen gibt: Setzt man diese Eigenschaft unter Windows 98 auf True, schmiert einem unweigerlich die Anwendung weg, obwohl sich mit 4 Zeilen zusätzlich der Fehler umgehen ließe.
Stecky2000 hat folgendes geschrieben : |
Manchmal bekommt man eben doch keine Antwort, was für Leute wie mich frustrierend ist.
Ich kann zwar einigermaßen das programmieren was ich brauche, doch um analytisch heraus zu finden, warum z. B. D7 anders arbeitet als D2010 und dann die entsprechende Lösung zu finden, dafür reicht es nicht immer. |
Viele Unterschiede sieht man wenn man einmal mit Einzelschritten durchdebuggt. Es ist eigentlich eher selten, dass man dann wirklich mal auf Low-Level-Ebene nachschauen muss, was da schiefgeht.
Und der grundlegende Umgang mit dem Debugger wird halt von vielen einfach vorausgesetzt, weil sich viele Fragen allein durch ein wenig Single-Stepping in der fraglichen Routine bereits beantworten ließen. Mehr zu diesem Thema aber in nem andren Thread, sonst wird das hier zu OT.
Stecky2000 - Mo 22.03.10 18:17
Wollte mal kurz Rückmeldung geben:
also, Lösung 1:
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10:
| var s: String; sv: Variant;
begin
s := '-'; sv := s;
Excel.Cells[zeile, spalte] := sv; |
löst einen EOleSysError (Falscher variablentyp) aus.
Lösung 2:
funktioniert wie gewünscht. ;-)
Der ASM zeigt übrigens folgendes an (mit '-', also mit Fehler):
Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25:
| 006AC126 E8DDEBE8FF call TStringGrid.GetCells 006AC12B 8B850CFFFFFF mov eax,[ebp-$000000f4] 006AC131 BA1CDB6A00 mov edx,$006adb1c 006AC136 E89DB8D5FF call @UStrEqual 006AC13B 755B jnz $006ac198 DPLUnit.pas.3660: Excel.Cells[i+(StrToInt(V_Ini_Excel_SchichtFolgenRasterX)-1), j+(StrToInt(V_Ini_Excel_SchichtFolgenRasterY)-1)] := '-'; 006AC13D 6A2D push $2d 006AC13F A138AA6C00 mov eax,[$006caa38] 006AC144 8B00 mov eax,[eax] 006AC146 E8958BD6FF call StrToInt 006AC14B 48 dec eax 006AC14C 0345EC add eax,[ebp-$14] 006AC14F 50 push eax 006AC150 A1FCAA6C00 mov eax,[$006caafc] 006AC155 8B00 mov eax,[eax] 006AC157 E8848BD6FF call StrToInt 006AC15C 48 dec eax 006AC15D 0345F0 add eax,[ebp-$10] 006AC160 50 push eax 006AC161 6804DB6A00 push $006adb04 006AC166 8D45B0 lea eax,[ebp-$50] 006AC169 50 push eax 006AC16A 6A00 push $00 006AC16C E85770D7FF call @DispInvoke 006AC171 83C418 add esp,$18 |
Moderiert von
Narses: Code-Tags hinzugefügt
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!