SoftMaker.de

Hallo,

gibt es irgendwo ein Beispiel, wie ich über OLE-Programmierung in eine Zelle einen Wert schreiben kann? Ich programmiere zwar in C++, wenn ich aber ein gutes Beispiel finde kann es auch in eine anderen Programmiersprache geschrieben sein.

Der Aufruf von PlanMaker klappt schon

Variant PM;
PM = GetActiveOleObject(cApplication);
PM.OlePropertySet("Visible", true);
....
, aber die Zellen zu füllen leider nicht.

Danke

Es gibt ein paar Skripte hier im Forum wo man abgucken kann, wie das geht. Alternativ helfen auch die mitgelieferten Muster.

Ansonsten wäre es sicher interessant zu wissen was anstelle der "..." bei Dir im Programm steht, damit man dem Fehler auf die Spur kommen kann.

Hab mir mal ein Beispiel (PlanMakerDemo) angeschaut und den Fehler gefunden . Der Range Befehl wurde falsch übergeben. Leider ist es so, das jedes System etwas anders arbeitet.

Anbei für alle, die in C++ programmieren hier ein Beispiel:

void __fastcall TArtikelForm::Beispiel
TObject *Sender)
{

AnsiString cApplication = "Planmaker.Application";
AnsiString cWorksheet = "ActiveSheet";
AnsiString cItem = "Name"; // Die Variablennamen sind extra mal nicht angepasst, weil
AnsiString cCells = "Range"; // es in anderen Systemen anders läuft und
// es in meinem System eine Fallunterscheidung gibt.

Variant PM;

PM = CreateOleObject(cApplication);

PM.OlePropertySet("Visible", true);

try
{

Variant WorkBooks = PM.OlePropertyGet("WorkBooks");
WorkBooks.OleFunction("Add");

Variant ActiveWorkBook = PM.OlePropertyGet("ActiveWorkbook");

Variant WorkSheets = PM.OlePropertyGet(cWorksheet);

Variant WorkSheet;

WorkSheet = WorkSheets.OlePropertyGet(cItem);

WorkSheets.OleFunction("Activate");

Range = WorkSheets.OlePropertyGet(cCells,"A1","A1");

Range.OlePropertySet("Value", "Ausgabe einer SQL-Auswertung");

// Weitere Anweisungen um das Datenblatt zu füllen....

}
catch(...)
{

}
}

Das ist Borland-Zeug, richtig? Kenne mich in den Dialekten nicht so aus.

Danke für das Beispiel. C++ und OLE interessiert mich. Wenn du vielleicht (muss nicht dieses Mal sein) ein komplettes Beispiel, gezippt, an einen deiner Beiträge anhängen könntest, wäre ich interessiert daran, das zum Laufen zu bringen und dafür aber irgendeinen Gnu-Compiler zu verwenden. Könnte mich hinreißen lassen, im Urlaub mal Trolltechs Active-X Zeug zu versuchen und damit zu vergleichen...

Hallo,
ja richtig, das ist Borland C++ (Zeugs ).
Die Funktion an sich ist lauffähig. Leider kann ich ein vollstädiges, lauffähiges Programm nicht einfach mit ranhängen (im Moment), weil ich an einem (komplexeren) Projekt arbeite, was schon Excel und OpenOffice OLE-Ansteuerung beinhaltet. Um das für GNU C++ zu benutzen müssen natürlich die Eigenarten des Borland C++ raus, was theoretisch aber nicht so ein Problem sein sollte.

Btw. musste ich leider feststellen, das im PlanMaker die Buchstaben übergeben werden müssen. In Excel und OpenOffice reicht es in der Angabe der Zeilen und Spalten einfach die Werte einzutragen (x,y) , bzw. (y,x) für OpenOffice. Hier hab ich das "Problem" immer vorher noch den Buchstaben zu berechnen (A1,A2 ...B1,B2)

int x = 0
char xChar[2];
xChar[0] = 65+x; //Buchstaben berechnen; Anfang 'A' = 65; x = Laufvariabel um z.B. 'B' zu erhalten
xChar[1] = 0x0;
AnsiString xWert = xChar;

AnsiString yWert = xWert + "3";

Range = WorkSheets.OlePropertyGet(cCells, yWert.c_str() ); // Wert in A3 schreiben!!

Ich frage mich, warum das so in PlanMaker gemacht wurde, oder fehlt mir hier einfach wissen?

Gruß

Es geht immerhin für eine Zelle. Schön länger versuch ich hier auf den Misstand aufmerksam zu machen, ohne merkliche Reaktion. Dazu noch fehlt die Eigenschaft Range.Address(AbsoluteOrRelative) - oder .Coordinates() - sehr spürbar, da man ja zur Verwendung von Adress-Strings gezwungen ist. .Range.Sheet gibts aber.
Deshalb ist man bei mehrzelligen Bereichen wirklich gezwungen eine Hilfsfunktion für Bereichsadressen mitzuschleppen. Bei benannten Bereichen wird es noch unangenehmer. PlanMaker findet sie nur auf dem ActiveSheet. Man muss in einer Error Schleife alle Sheets durchprobieren.

Tacheles: Alle Zellen des Blattes, von A1 aus.
Set MyRange = PM.ActiveSheet.Cells(RowNumber,ColumnNumber)

Alle Zellen des Blattes, von Startzelle von MyRange (li.ob.) aus. Range als Tochter von Range:
MyRange.Item(RowIndex, ColumnIndex).Formula = cellContents$
Item ist default -> weglassen. Indizes können negativ sein. Größe von MyRange irrelevant.

Mehrzellige Bereiche wie Du wohl weist nur so: .Range("A1:B2") oder .Range("A1", "B2")
Ganze Spalten: .Range("C:F")
Ganze Zeilen: .Range("3:16")

_________________
SMO rev. 670 + Win XP                    Times without money are better than times without Mini - the original

Von benannten Bereichen mal abgesehen (wobei das in sich eine Komplikation enthält, deren man sich bewusst ist), halte ich das für einen recht sanft aufgedrückten Zwang. Vielleicht, weil die "Hilfsfunktion" immer die gleiche ist. Kennt Basic eigentlich Hashes oder Maps? Freilich muss sich das Office-Skripting für mich nicht in bare Münze umsetzen lassen, darum kann ich leicht reden. Aber solche Krücken möchte ich gerne einmal (1x) zentralisieren und dann vergessen. Es ist unbequem aber kein wirklicher Missstand. IMHO.

Es ist ja wirklich ertragbar. Dennoch würde ich gern mit einer genau gegenteiligen Denkweise ergänzen.

Mir war es nur solange unbequem, bis in meiner Vorlage für neue Skripte Function Address(rangeObject) stand. Aber jedesmal wenn ich sie sehe, bei jedem etwas anspruchsvolleren Skript, wird mir unwohl. Ein Missstand, der - bei SMO wohl eher ungerechtfertigte - Rückschlüsse provoziert.

Dass Adress-Strings in der PM Objektstruktur zwar benötigt, aber nicht geboten werden, ist eben -- ein strukturelles Problem. Der obige Beitrag beweist, dass es Nichts mit Basic oder sonstigen Sprachen zu tun hat. Und er bestätigt meine Erfahrung, dass andere Büro Anwendungen (zumindest dieses Problem) vermieden haben.

Strukturelle Probleme machen mir Magendrücken, weil sie wiederholten pragmatischen Mehraufwand tolerieren. Sie stören das Vertrauen, dass von barer Münze gefordert wird. Wenn man dem Skripten für eine Büroanwendung einen Sinn oder Nutzen unterstellt, geht es genau darum. Einen langfristigen Mehraufwand mittels einmaliger Investition zu vermeiden.

_________________
SMO rev. 670 + Win XP                    Times without money are better than times without Mini - the original

Hallo,

ich habe einen entsprechenden Verbesserungsvorschlag an die Entwickler weitergeleitet und werde mich wieder melden, sobald es hierzu etwas neues gibt.

_________________
Sven Leßmann
SoftMaker Software GmbH

Dankeschön!

_________________
SMO rev. 670 + Win XP                    Times without money are better than times without Mini - the original