OpenOffice.info

Verfasst: **Fr, 03.02.2012 12:04**

Mahlzeit.

@gogo
Das Du während der Laufzeit ein zusätzliches Modul erstellst, und anschließend wieder löscht, das war mir auch aufgefallen. Nur der gesammte zusammenhang fehlte mir noch. Mit deiner jetzigen Erklärung hast Du aber Licht ins dunkel gebracht.

@Fieder

Aber es ist definitive mehr Arbeit , als wenn man einen User-Type Verwendet, und außerdem viel Fehleranfälliger.

Viel Arbeit, ja. Aber ob Fehleranfälliger, weiß ich nicht. Wie kommst Du dadrauf? Bezogen auf die komplexibilität der Function besteht natürlich ein größeres Fehlerpotenzial beim nachbauen und verstehen. Jedoch würde ich momentan sagen das sie wohl Fehlerfrei funktioniert. Oder hast Du was herausgefunden was dem widerspricht?

(könnt ihr nicht ein bischen langsamer sein. ich kann nicht so schnell tippen wie ihr jetzt antwortet

)

Die jetzigen Lösungsvorschläge von euch funktionieren, aber das wollte ich ja eigentlich ursprünglich vermeiden. Was leider nicht so funktioniert wie ich anfangs dachte.

Ich frag mich nur warum ihr euch beide das so schwer macht?
Es braucht kein "NotUselesType" und auch keine 'Nachnamen' der Variablen Mase(mi), und auch kein 2D-Array. Es reicht einfach.

Code: Alles auswählen

	Dim Mase(2 to 24) as  string
	Dim MaseV(2 to 24) as  Variant ' - oder auch Double

	Mase(8) = "oDiagram.getSize.Height"

	MaseV(8) =  oDiagram.getSize.Height

	For mi = 2 to 24
		ZelleN = oBlatt2.getCellRangeByName("A" & mi)
	ZelleN.string = Mase(mi)
		ZelleM = oBlatt2.getCellRangeByName("B" & mi)		
		ZelleM.value = MaseV(mi)
	next mi

Damit will ich nicht eure Ideen nicht würdigen, oder herabstufen, sondern nur mitteilen das es auch etwas "einfacher" geht.

Ich sitze jetzt hier und habe einiges zum Studieren.

Ich Danke euch noch mal für eure Mitarbeit und für eure Idden.

Gruß
balu

Verfasst: **Fr, 03.02.2012 12:40**

Hallo blau

Viel Arbeit, ja. Aber ob Fehleranfälliger, weiß ich nicht. Wie kommst Du dadrauf? Bezogen auf die komplexibilität der Function besteht natürlich ein größeres Fehlerpotenzial beim nachbauen und verstehen. Jedoch würde ich momentan sagen das sie wohl Fehlerfrei funktioniert.

Die Funktion ist viel fehleranfällig 1. bezüglich des Programmierens und 2. bezüglich der späteren Anwendung.

Ich frag mich nur warum ihr euch beide das so schwer macht?
Es braucht kein "NotUselesType" und auch keine 'Nachnamen' der Variablen Mase(mi), und auch kein 2D-Array. Es reicht einfach. ...

Alle 3 Lösungen sind bezüglich der Komplexität und des Aufwandes etwa gleich unkompliziert, und liefern das gleiche Ergebnis.
Es ist also nur eine Geschmacksache, welche der 3 Möglichkeiten man bevorzugt.
Alle 3 Lösungen produzieren wesentlich besser lesbaren Code als die Lösung, bei der ein neues Modul erzeugt wird,
und helfen so Fehler beim Programmieren zu vermeiden.
Der Trick bei allen 3 Lösungen, wie man sich die Arbeit Leichter machen kann,
ist dass man den Code nur für z.B. die Strings per Hand schreibt,
und dann den Code für die Werte mit einer Formel in einer Calc-Tabelle erzeugt,
so wie ich das in der Tabelle3 meines Beispiels gezeigt habe.

Gruß Frieder

Verfasst: **Fr, 03.02.2012 12:52**

Hallo
Ich würde auf die magische Dimensionierung 2 to 24 verzichten und auf die for-Schleife über den Zellbereich, es gibt ...setDataArray:

Code: Alles auswählen

sub set_data_array()
	data = array(array("Name","Karolus"),_
				array("Größe", 1.85),_
				array("Gewicht", 66.5))
	'↓nachträgliche Änderung
	data(0)(1)="Balu"
	range = Thiscomponent.sheets(1).getCellRangebyName("A4:B6")
	range.setDataArray( data )
end sub

Gruß Karo

Verfasst: **Fr, 03.02.2012 13:37**

Servus

Frieder D. hat geschrieben:Es ist also nur eine Geschmacksache, welche der 3 Möglichkeiten man bevorzugt.

Würde ich nicht sagen, User Defined Types sind eine unausgegorene Sache mit einigen Pitfalls, daher bei der Arbeit mit OOo Makros allen meinen bisherigen Erfahrungen nach unbrauchbar. Und überflüssig obendrein.
Die Herangehensweise, die ich persönlich verwenden würde, wäre entweder ein 2-Dimensionales Array oder, sogar noch eher, zwei seperate Arrays.

Frieder D. hat geschrieben:Der Trick bei allen 3 Lösungen, wie man sich die Arbeit Leichter machen kann

Naja, was heisst Arbeit leichter machen? Wenn Du bei jeder Änderung erstmal über ein Calc-Sheet oder ähnliche Hilfsmittel Deinen Quellcode produzieren lassen musst, ist das nichts, worüber man ernsthaft nachdenken kann.

Frieder D. hat geschrieben:Aber es ist definitive mehr Arbeit , als wenn man einen User-Type Verwendet

Das musst Du mir erklären - das Konzept von Funktionen ist ganz simpel: einmal die Arbeit investieren, um sie zu schreiben, danach einfach verwenden.
Auch wenn ich Workarounds wie das hier besprochene Erzeugen temporärer Module / Bibliotheken niemals auf beruflicher Ebene anwenden würde, vermutlich nichtmal auf "privater", so kann man eins definitiv festhalten: es ist weniger Arbeit, als wenn man einen User-Type, ein Array o.Ä. verwendet.

Verfasst: **Fr, 03.02.2012 16:17**

Hallo ihr lieben!

Ich ziehe jetzt mal folgendes Fazit.

Mein Eingangsproblem lässt sich schon mit Argen verrenkungen lösen, so wie z.B. DPunch es mit seiner Datei detailiert zeigte. Für mich ist das natürlich sehr interessant zu sehen. Und da ich ja nicht nur mal eben von 2 oder 3 Eigenschaften die Werte auslesen wollte, steht der zusätzliche Arbeitsaufwand mit der Komplexen Function eigentlich auch in einer guten Relation. Ich kann jetzt sogar noch einige Eigenschaften zusätzlich abfragen, ohne die Function dafür noch anzupassen zu müssen. Von daher ist sie sehr Flexibel, was ja auch den Sinn einer Function ausmacht.

Wenn es nur darum geht ein paar wenige Eigenschaften abzufragen ( weniger als 5 zum Beispiel), dann sind die anderen Vorschläge durchaus empfehlenswert. Die Idee von Karo geisterte mir wohl auch schon durch den Kopf, aber bei der praktischen Umsetzung haperte es doch. Dafür fehlte mir das nötige Wissen solche ein Array zu erstellen. Aber ich habe jetzt seinen Vorschlag verstanden, und auch in die Tat umsetzen können.

Code: Alles auswählen

data = array(array("rect.Height",rect.Height),_
	array("rangeAddress(0).StartRow",rangeAddress(0).StartRow),_
	array("rangeAddress(0).EndRow",rangeAddress(0).EndRow),_
	array("oDiagram.getSize.Height",oDiagram.getSize.Height),_
[...]
	range = Thiscomponent.sheets(1).getCellRangebyName("A2:B24")
	range.setDataArray( data )

Es ist eigentlich eine Verschmelzung von den letzteren Vorschlägen.

@Fieder
Ach ja, was die Fehleranfälligkeit betrifft! Egal wie und wo, die können überall auftreten. Das ist halt so.

Ich Danke euch allen für die ganzen Ideen und Vorschläge. Habe nicht nur in hinsicht auf mein Eingangsproblem was dazu gelernt. Nein! Auch in den anderen Vorschlägen steckt einiges drin was ich mir an anderer Stelle zu Nutze machen kann

.

Gruß
balu

Verfasst: **Fr, 03.02.2012 16:35**

DPunch hat geschrieben: Würde ich nicht sagen, User Defined Types sind eine unausgegorene Sache mit einigen Pitfalls, daher bei der Arbeit mit OOo Makros allen meinen bisherigen Erfahrungen nach unbrauchbar. Und überflüssig obendrein.

Ich habe bis jetzt noch nie Probleme mit UserTypes gehabt. Könntest du bitte erklären, was für Fallgruben du meinst?
Ich würde dir recht geben, wenn du sagen würdest, dass man alles was man mit UserTypes machen kann auch anders lösen kann, aber das heißt nicht, dass sie Überflüssig sind.
Zum teil ist der Code einfach besser lesbar, wenn man UserTypes statt Arrays nimmt, da man dann weiß, was die Variable für einen wert hat.
Hier ein echtes Beispiel von mir: (i und j sind Schleifen Indices)

Code: Alles auswählen

Type masterType 'Enthält alle Werte aus der Makro-Tabelle für die Vorlagen.
  masterKey As Integer 'Vorlagen-Nummer
  smasterName As String 'Vorlagen-Name
  nStartRow1 As Long 'Erste Zeile Formeln
  nStartRow2 As Long 'Zweite Zeile Formeln
  sPrintArea1 As String '1. Druckbereich
  sPrintArea2 As String '2. Druckbereich
  nNumberOfDoc AS Integer 'Anzahl der zu erstellenden PDFs
  fRestZeilenumbruch1 As Single 'Zeilenumbruch1
  fRestZeilenumbruch2 As Single
  sCondition1 As String 'Erste Bedingung
  sAnd_Or As String 'Verknüpfung
  sCondition2 As String '2. Bedingung
  nProject As Integer 'Spalte, nach der neues Blatt erzeugt wird (offset)
  sSortCond As string
End Type
...
Dim masters( 100) As masterType
...
masters(j).fRestZeilenumbruch1 = oSheet.getcellbyposition(7,18+i).Value

die Namen sind einfach aussagekräftiger als :

Code: Alles auswählen

...
Dim masters(13,100)
...
masters(7,j)= oSheet.getcellbyposition(7,18+i).Value

Mit 14 eindimensionalen Arrays habe ich zwar auch die Namen, aber so sehe ich gleich, welche Variablen zusammen gehören,
da ich in dem Code auch noch andere Arrays verwende, die aber ganz andere Daten enthalten.
Noch ein Grund, warum 14 eindimensionalen Arrays in meinem Fall nicht in Frage kommen ist, dass "masters()" mehrmals an verschiedene Funktionen übergeben wird.
Und ich möchte nicht 14 einzelne Arrays an eine Funktion übergeben müssen.

DPunch hat geschrieben:Die Herangehensweise, die ich persönlich verwenden würde, wäre entweder ein 2-Dimensionales Array oder, sogar noch eher, zwei seperate Arrays.

In diesem Fall gebe ich dir recht, da dadurch die Methode setDataArray statt einer Schleife verwendet werden kann.(enormer Geschwindigkeitsgewinn)

DPunch hat geschrieben: Naja, was heisst Arbeit leichter machen? Wenn Du bei jeder Änderung erstmal über ein Calc-Sheet oder ähnliche Hilfsmittel Deinen Quellcode produzieren lassen musst, ist das nichts, worüber man ernsthaft nachdenken kann.

Das muss man ja nicht für jede kleine Änderung machen.beim ersten Erzeugen ist das aber schon ein Forteil,
denn es macht einen gewaltigen Unterschicht, ob ich 2mal 22 Zeilen schreiben muss, oder eben nur einmal + eine kleine Formel.
(je mehr zielen, desto grösser der Zeitgewinn.)

DPunch hat geschrieben: Das musst Du mir erklären - das Konzept von Funktionen ist ganz simpel: einmal die Arbeit investieren, um sie zu schreiben, danach einfach verwenden.
Auch wenn ich Workarounds wie das hier besprochene Erzeugen temporärer Module / Bibliotheken niemals auf beruflicher Ebene anwenden würde, vermutlich nichtmal auf "privater", so kann man eins definitiv festhalten: es ist weniger Arbeit, als wenn man einen User-Type, ein Array o.Ä. verwendet.

Es ist nur dann weniger arbeit, wenn die Funktion schon fertig ist:
Array: 22 Zeilen+ eine leichte Calc-Formel = 23 Zeilen
Funktion: 22 Zeilen +39 Zeilen komplizierte Funktion = 61 Zeilen
(Wahrscheinlich mehr, da man bestimmt ein par Änderungen während des Programmierens vornehmen muss.)

Gruß Frieder

Verfasst: **Fr, 03.02.2012 19:51**

Servus

Frieder D. hat geschrieben:Ich habe bis jetzt noch nie Probleme mit UserTypes gehabt. Könntest du bitte erklären, was für Fallgruben du meinst?

Dynamische Speicherallokation innerhalb der UDT, Neudimensionierung von UDT-Arrays, CopyByReference von UDT, Sichtbarkeit von UDT, Abwärtskompatibilität (da war was zwischen glaube zwischen 3.1 und 3.2)... und irgendwas war da noch, was mir derzeit nicht einfallen will.
Über das Mehr an Lesbarkeit im Einzelfall lässt sich nicht streiten, da gebe ich Dir ohne Zweifel Recht, aber im Gesamtkontext beeinträchtigt es (meiner Meinung nach) die Lesbarkeit deutlich mehr, wenn Du aufgrund der Beschränkungen gezwungen bist, auf einmal Hilfsfunktionen bereitzustellen, nur um Deine UDTs Library-weit verfügbar zu machen, um sie neu zu dimensionieren etc.
Oder, noch schlimmer, immer wieder auf einen anderen Weg ausweichen musst, weil die Verwendung des wohldurchdachten UDT zu viele Verrenkungen erfordern würde.
Dann lieber einen einheitlichen Weg, der auf den ersten Blick Lesbarkeit einbüßt, aber dafür eben nachvollziehbar bleibt.

Frieder D. hat geschrieben:aber das heißt nicht, dass sie Überflüssig sind.

Wenn Du sie als hilfreich erachtest, können sie ja schon per Definition nicht überflüssig sein - da dies aber ein Forum ist, habe ich meine persönliche Meinung dazu geäußert, die weder Anspruch auf Richtigkeit noch auf Verbindlichkeit hat. Insofern möglicherweise falsche Wortwahl, ohne dass das meine Meinung ändern würde.

Frieder D. hat geschrieben:Mit 14 eindimensionalen Arrays habe ich zwar auch die Namen, aber so sehe ich gleich, welche Variablen zusammen gehören

Wie gesagt, von der Lesbarkeit her kein Widerspruch, aber parallele Arrays bieten Möglichkeiten, die auch ungeachtet der oben beschriebenen Probleme UDT zu einer (für mich) überflüssigen Sache machen. Wie liest Du Eigenschaften plus deren Werte aus einem UDT aus? Vermutlich nicht einfach mit einer Schleife.

Frieder D. hat geschrieben:Und ich möchte nicht 14 einzelne Arrays an eine Funktion übergeben müssen

Dazu habe ich selbst bei den aufwändigsten Extensions noch keine Notwendigkeit gesehen, insofern kann ich zu dem Argument wenig sagen.

Frieder D. hat geschrieben:Das muss man ja nicht für jede kleine Änderung machen.beim ersten Erzeugen ist das aber schon ein Forteil
(...)
Es ist nur dann weniger arbeit, wenn die Funktion schon fertig ist

Wie schon erläutert ist genau das ja das Prinzip von Funktionen - einmal die Arbeit investieren, im Optimalfall nie wieder anfassen müssen.
Steht die Funktion einmal, kann man (bzw. könnte man) sich damit auch einfach 22 EIgenschaften von thisComponent und 22 Eigenschaften von thisComponent.Sheets.getByIndex(0) anzeigen lassen - ohne Calc-Formeln zu bemühen, sondern durch einmaliges Festlegen der gewünschten Eigenschaften + Deklaration der entsprechenden Objekte (mindestens) Modulweit.

OpenOffice.info

String in einen "Befehl" umwandeln

Re: String in einen "Befehl" umwandeln

Re: String in einen "Befehl" umwandeln

Re: String in einen "Befehl" umwandeln

Re: String in einen "Befehl" umwandeln

Re: String in einen "Befehl" umwandeln

Re: String in einen "Befehl" umwandeln

Re: String in einen "Befehl" umwandeln