sub test6
dim List(3)
dim tmpList(2)
for n = 0 to 3
tmpList(0) = n
tmpList(1) = n
tmpList(2) = n
List(n) = tmpList
next n
end sub
Meine Erwartung war, dass sich im Array "List" am Ende vier "Unterarrays" befinden, die mit unterschiedlichen Werten gefüllt sind. Also
(0, 0, 0)
(1, 1, 1)
(2, 2, 2)
(3, 3, 3)
Stattdessen ergalte ich
(3, 3, 3)
(3, 3, 3)
(3, 3, 3)
(3, 3, 3)
Ist das normal und so gewollt? Kann ich mir irgendwie nicht vorstellen.
Ich habe jetzt schon eine längere Zeit nichts mehr programmiert, bin mir aber relativ sicher, dass das vor einiger Zeit noch nicht so war. Oder stehe ich hier gerade komplett auf dem Schlauch...?
Bin dankbar für eure Kommentare!
Zuletzt geändert von drbrode am Do, 14.09.2023 08:28, insgesamt 1-mal geändert.
so einfach … und trotzdem kleben die Helden am Basic!
Ist leider nicht meine Entscheidung. Für meine Firma erstelle ich Tabellen mit Makrofunktionen zur Datenverarbeitung. Das Ganze so nebenbei, weil es niemand anders kann und kein Geld für "richtige" Software ausgegeben wird. Dazu kommt noch, dass unsere IT besessen ist vom Sicherheitsgedanken und so gut wie keine zusätzliche Software auf den Arbeitsplatzrechnern zulässt. Ich muss also mit Bordmitteln auskommen.
Mir ist bewusst, dass meine Erklärung voller Widersprüche ist. Aber es ist nunmal die Realität...
so einfach … und trotzdem kleben die Helden am Basic!
Ist leider nicht meine Entscheidung. Für meine Firma erstelle ich Tabellen mit Makrofunktionen zur Datenverarbeitung. Das Ganze so nebenbei, weil es niemand anders kann und kein Geld für "richtige" Software ausgegeben wird. Dazu kommt noch, dass unsere IT besessen ist vom Sicherheitsgedanken und so gut wie keine zusätzliche Software auf den Arbeitsplatzrechnern zulässt. Ich muss also mit Bordmitteln auskommen.
Mir ist bewusst, dass meine Erklärung voller Widersprüche ist. Aber es ist nunmal die Realität...
python ist seit mindestens 20 Jahren »ein Bordmittel« in OpenOffice … AOO…Libreoffice, im Idealfall (also bei Linux-distributionen) dann direkt gegen den python-interpreter des Systems gelinkt.
LO7.4.7.2debian 12(bookworm) auf Raspberry4b 8GB (64bit) LO24.8.2.1 flatpakdebian 12(bookworm) auf Raspberry4b 8GB (64bit)
sub test6
dim List(3)
for n = 0 to 3
List(n) = array(n, n, n)
next n
end sub
Das wäre sicherlich ein workaround, wenn auch ein wenig komplizierter.
Was mich aber eigentlich wurmt, ist das Verhalten des Codes an sich. Ich weise doch in jeder Schleife den Elementen meines Arrays "List" das Array "tmpList" zu. Meines Wissens sollten im Array "List" dabei doch nur die Inhalte von tmpList gespeichert werden. Stattdessen wird aber anscheinend die Variable "tmpList" selbst zugewiesen, was zur Folge hat, dass eine nachträgliche Änderung von "tmpList" Einfluss auf die Werte des Arrays "List" hat. Das dürfte doch so eigentlich nicht sein...
python ist seit mindestens 20 Jahren »ein Bordmittel« in OpenOffice … AOO…Libreoffice, im Idealfall (also bei Linux-distributionen) dann direkt gegen den python-interpreter des Systems gelinkt.
Das ist jetzt ein wenig "off-topic" aber Oo verlangt bei der Erstellung von javascript- und auch python-Makros eine JAVA-Laufzeitumgebung (JRE). Die gibts bei mir anscheinend nicht.
Nein, du füllst in jedem Durchlauf »tmpList« mit neuen Werten, das ändert aber global »tmpList« und deshalb hast du am Ende alles mit Werten aus dem letzten Schleifendurchlauf. (python würde sich da genauso verhalten, wenn ich das so kompliziert hinschreibe)
LO7.4.7.2debian 12(bookworm) auf Raspberry4b 8GB (64bit) LO24.8.2.1 flatpakdebian 12(bookworm) auf Raspberry4b 8GB (64bit)
Das ist jetzt ein wenig "off-topic" aber Oo verlangt bei der Erstellung von javascript- und auch python-Makros eine JAVA-Laufzeitumgebung (JRE). Die gibts bei mir anscheinend nicht.
Nein … das ist eine falsche Fehlermeldung die seit langem in OO|AOO auftaucht. Die JRE wird nur noch für Datenbankanbindungen gebraucht.
Arbeitet deine Firma tatsächlich noch mit AOO? Wirds da nicht mal Zeit auf LibreOffice zu wechseln?
Das wäre sicherlich ein workaround, wenn auch ein wenig komplizierter.
Warum ist das ein »workaround« und was zum Geier ist da jetzt komplizierter ( so allgemein im Vergleich zu deiner offenbar nicht funktionierenden Lösung) ??
LO7.4.7.2debian 12(bookworm) auf Raspberry4b 8GB (64bit) LO24.8.2.1 flatpakdebian 12(bookworm) auf Raspberry4b 8GB (64bit)
Karolus hat geschrieben: Mi, 13.09.2023 12:38
Nein, du füllst in jedem Durchlauf »tmpList« mit neuen Werten, das ändert aber global »tmpList« und deshalb hast du am Ende alles mit Werten aus dem letzten Schleifendurchlauf. (python würde sich da genauso verhalten, wenn ich das so kompliziert hinschreibe)
Will dich nicht nerven aber da muss ich jetzt nochmal nachhaken. Folgender Code (ich weiß das macht so keinen wirklichen Sinn, es geht mir aber ums Prinzip)
sub test
dim List(3)
for n = 0 to 3
a = n
List(n) = a
next n
end sub
liefert als Ergebnis ein Array mit
0
1
2
3
Hier wird doch genauso den Elementen des Arrays "List" eine Variable "a" zugewiesen, die sich mit jedem Durchlauf ändert. Trotzdem wirkt sich die nachträgliche Änderung von "a" in diesem Fall nicht auf die vorherigen Elemente des Arrays aus. Der einzige Unterschied ist, dass diesemal nicht ein Array sondern eine einzelne Variable zugewiesen wird.
Hallo
»a« wird in jedem Durchlauf neu definiert, das ist bei tmpList nicht geschehen, da hast du lediglich den Inhalt der bestehenden tmpList geändert!
Fällt der Groschen?
LO7.4.7.2debian 12(bookworm) auf Raspberry4b 8GB (64bit) LO24.8.2.1 flatpakdebian 12(bookworm) auf Raspberry4b 8GB (64bit)
Karolus hat geschrieben: Mi, 13.09.2023 13:11
Hallo
»a« wird in jedem Durchlauf neu definiert, das ist bei tmpList nicht geschehen, da hast du lediglich den Inhalt der bestehenden tmpList geändert!
Fällt der Groschen?
Da fehlen mir anscheinend ein paar Grundkenntnisse. Ich checks auch nicht wirklich...
übertrage ich doch den Inhalt von "tmpList" auf "List(n)". "List(n)" enthält danach doch ein Array mit dem Inhalt (1, 1, 1) (zum Beispiel). Was hat denn dieser Inhalt danach dann noch mit dem Array "tmpList" zu tun?
übertrage ich doch den Inhalt von "tmpList" auf "List(n)".
nein du steckst die komplette tmplist in die Position n von List, im nächsten Durchlauf überschreibst du nicht tmplist als ganzes sondern nur deren Inhalte.
Ich hab dir mal ne msgbox eingebaut die am Ende der Schleife den Inhalt von List(0) ausgibt.
sub test7
dim List(3)
dim tmpList(2)
for n = 0 to 3
tmpList(0) = n
tmpList(1) = n
tmpList(2) = n
List(n) = tmpList
if n=0 then
msgbox( "ich bin tmplist mit dem Inhalt" &chr(10) & join(List(0), chr(10)))
else
msgbox( "ich bin immernoch tmplist aber mit neuem Inhalt" &chr(10) & join(List(0), chr(10)))
end if
next n
end sub
LO7.4.7.2debian 12(bookworm) auf Raspberry4b 8GB (64bit) LO24.8.2.1 flatpakdebian 12(bookworm) auf Raspberry4b 8GB (64bit)
OK... ich habe den entsprechenden Eintrag jetzt bei Pitonyak (Kapitel 3.5.2) gefunden.
Dort wird das Verhalten mit Beispielen beschrieben. Ich habe schon so einiges programmiert aber das war mir komplett neu. Jetzt habe ich es aber kapiert.
Ich danke dir vielmals für deine Geduld und den Crashkurs!
hier erwartest du doch auch das »some_list« geändert wird, und in deinem Ausgangspost tust du sinngemäss das gleiche, (es macht halt keinen Unterschied ob du »tmplist« zwischendrin in einen anderen Koffer steckst oder nicht!
LO7.4.7.2debian 12(bookworm) auf Raspberry4b 8GB (64bit) LO24.8.2.1 flatpakdebian 12(bookworm) auf Raspberry4b 8GB (64bit)