Excel Zahlen werden als Zahl formatiert müssen aber angeklickt werden

[Chemiker]

Hallo,

was man machen kann, dass man den Wert nach der Formatierung überschreibt:

Delphi-Quellcode:

    zahl: Extended;     

   if TryStrToFloat(ExcelApp.Range['A1','A1'].value2, Zahl) then
   begin
     ExcelApp.Range['A1','A1'].EntireColumn.NumberFormat:= '#,###.00';
     ExcelApp.Range['A1','A1'].Value2:= Zahl;
   end;

Bis bald Chemiker

[Jumpy]

Wenn es am NumberFormat liegen sollte, kann man in Excel auch NumberFormatLocal verwenden, dann müsste er mit der deutschen Formatsmaske klar kommen. Aber wie gesagt, ich denke Excel versteht es ja, berechnet/evaluiert nur die Zellen nicht neu.
Da die Daten ja aus einem StringGrid kommen denke ich das alles als Text bei Excel reingeschrieben wird. Jetzt gibst du der Zelle mit einer Zahl als Text eine Zahlenformatierung und nun muss man Excel halt nur sagen, dass auch anzuwenden.

[oakley]

Also die Übergabe im ANSI Format (#,##0.00) funktioniert nicht, dann formatiert er falsch wenn ich auf die Zelle klicke.
Die Angabe #,##0.00 formatiert richtig als Zahl aber es bleibt das grüne Dreieck und Summen usw sind mit dem Werten nicht möglich.
Ein Klick mit der rechten Maustaste auf die Zelle bestätigt das Format als Zahl.

@Ralph: ja nur wie mache ich das? Wie bringe ich Excel dazu die Formatierung anzuwenden und nicht was eigenes zu generieren?

@Chemiker: habe ich so gemacht und es funktioniert. Danke !

LG

Mirko

[Delphi.Narium]

Zitat von oakley:

@Chemiker: Ich müsste dann wahrscheinlich durch jede Zelle in den Zahlenspalten "loopen" und neu schreiben, das würde sicher gehen.

Das Format muss für jede Zelle gesetzt werden und nicht nur für A1.

Wenn sich alle Daten "irgendwo" zwischen A1 und F97 befinden, dann könnte auch ein ExcelApp.Range['A1','F97'].EntireColumn.NumberFormat:= '#.###,00'; reichen.

ExcelApp.Range['A1','F97'] entspricht 6 Spalten und 97 Zeilen.

Du könntest es auch mal in der Form versuchen: ExcelApp.Range['A1',Format('%s%d',[Chr(StringGrid.Cols + 64),StringGrid.Rows])].EntireColumn.NumberFormat := '#.###,00';

Range ist der Bereich, für den das Format gelten soll. Wenn der Bereich mit ExcelApp.Range['A1','A1'] angegeben wird, dann gilt er auch nur für A1, also die erste Zelle oben links.

[Andreas13]

Hallo Mirko,
mich würde zur konkreten Nachvollziehung des Problems mal Dein Code für Deine ursprünglich nicht funktionierende Lösung interessieren, denn Du hast aller Wahrscheinlichkeit nach die Zahlen als Text an Excel übergeben.
Der funktionierende Vorschlag von Chemiker ExcelApp.Range['A1','A1'].Value2:= Zahl; erzwingt gerade diese Konvertierung des Strings in ein Zahlenformat.
Gruß, Andreas

[oakley]

Hallo Andreas,

ja da hast Du recht. Ich habe die Speicher Routine eines AdvStringgrid von TMS genommen und die hat die Daten einfach als Text übertragen.
Das war der Fehler. Die Neuformatierung hat dann alles wieder gerade gebogen.

Noch eine kurze Frage, da ich nur sehr selten so etwas mache wie Excel fernsteuern: Im Editor wird mir EntireColumn.Numberformat als undeklariert angezeigt bei

Code:

ExcelApp := CreateOleObject('Excel.Application');
ExcelApp.Range['A1','A1'].EntireColumn.Numberformat := '@';

Kann ich das irgendwie korrigieren?

LG

Mirko

[Andreas13]

Hallo Mirko,
die Programmzeile ExcelApp.Range['A1','A1'].EntireColumn.Numberformat := '@'; wird auch bei mir als undeklariert markiert, weil bei der vorliegenden "Frühen Bindung ohne Verwendung der Typbibliothek" die IDE über die importierten Routinen noch nichts "weiß". Die Stunde (Sekunde) der Wahrheit schlägt somit erst zur Laufzeit... Du mußt also die Routinen ausgiebig testen.
Noch etwas habe ich bei meiner Delphi-Version (XE5 Pro) unter Windows 10 beobachtet: Die übliche Anbindung von Excel mittels

Delphi-Quellcode:

Var
  Excel: Variant; 

Begin 
Try
  Excel:= GetActive0le0bject('Excel.Application'); 
Except
 Excel:= CreateOleObject('Excel.Application'); 
End;
...

ist bei mir unzuverlässig, weil GetActive0le0bject('Excel.Application'); bei mir beim Fehlen des Excel-Servers zwar eine EOLESysError-Exception auslöst, aber merkwürdigerweise nicht in den Except-Block springt, sondern einen Programm-Abbruch zur Folge hat. Daher mußte ich eine ich aus den beiden obigen Routinen eine zusammengefasste GetOrCreateOleObject(..) machen:

Delphi-Quellcode:

Uses
, Vcl.OleAuto
, Winapi.Ole2
;
Function MyOleCheck(Res: HResult): Boolean;
Begin
  Result:= Failed(Res);
End;{MyOleCheck}
{--------------}

Function GetOrCreateOleObject(Const ClassName: String): Variant;
VAR
  Unknown    : IUnknown;
  ClassID    : TCLSID;
  WideCharBuf: Array[0..127] of WideChar;
  Fehler     : Boolean;
  
Begin
  StringToWideChar(ClassName, WideCharBuf, SizeOf(WideCharBuf) div 2);
  OleCheck(CLSIDFromProgID(WideCharBuf, ClassID));

  // GetActiveOleObject:
  Fehler:= MyOleCheck(GetActiveObject(ClassID, NIL, Unknown));
  
  // CreateOleObject: 
  IF Fehler Then 
    Fehler:= MyOleCheck(CoCreateInstance(ClassID, NIL, CLSCTX_INPROC_SERVER OR CLSCTX_LOCAL_SERVER, IID_IUnknown, Unknown));
    
  Try
    Result:= VarFromInterface(Unknown);
  Finally;
    Unknown.Release;
  End;
End;{GetOrCreateOleObject}
{------------------------}
...
Begin
  Try
     Excel:= GetOrCreateOleObject('Excel.Application');
  ...

Auf diese Weise konnte ich auch nicht-visuelle Konsolen-Anwendungen "wasserdicht" machen. Vielleicht hilft es jemandem hier weiter.
Gruß, Andreas

[Andreas13]

… und noch etwas:

Zitat:

ja da hast Du recht. Ich habe die Speicher Routine eines AdvStringgrid von TMS genommen und die hat die Daten einfach als Text übertragen.
Das war der Fehler. Die Neuformatierung hat dann alles wieder gerade gebogen.

Das stimmt leider nicht. Durch einfaches Formatieren wird aus Excel's String-Zahlen, die jeweils einen Apostroph vor der Zahl haben (z. B. '1) noch keine Zahl. Probier es doch mal aus, indem Du nach der "Umformatierung" die Zahlenkolonne summierst oder mit ihnen andere arithmetische Operationen ausführst. Dann merkst Du sofort, daß es keine Zahlen, sondern Texte sind.
Gruß, Andreas

[Chemiker]

Hallo Andreas13,

der Except Block wird zuverlässig ausgeführt!
Du hast eine nicht ordnungsgemäße geschlosse Excel-Instanz im Hintergrund laufen. Im Task-Manager wird diese Instanz unter Prozesse angezeigt.

Bis bald Chemiker

[Andreas13]

Danke Chemiker, das war der Grund für den Programm-Absturz!
Gruß, Andreas