Erarbeitung eines "POS-Kassenbuchs"

Diskussionen zu Projekten

Moderator: Moderatoren

Forumsregeln
Dieses Unterforum versteht sich als Plattform zur Diskussion/Bearbeitung komplexerer Anfragen bzw. konkret verabredeter Projekte. Das können Dinge sein wie eine komplexere Calc-Datei oder auch die gemeinsame Programmierung eines größeren Makros, wichtig ist immer die Absicht ein Thema über längere Zeit (z.B. 3 Monate) fortlaufend zu besprechen.
Benutzeravatar
Julia NuN
**
Beiträge: 37
Registriert: Mo, 07.11.2016 14:57

Re: Erarbeitung eines "POS-Kassenbuchs"

Beitrag von Julia NuN » Mi, 14.12.2016 18:21

Hallo balu,
Da Du sicherlich nicht so recht den Zusammenhang zwischen meinen Fragen und dem Stichwort SVERWEIS verstehst, will ich das jetzt mal verdeutlichen. Auch wenn es jetzt eigentlich so nicht mehr von nöten ist.
Da war ich aber auf dem Holzweg, als du von "wegschließen" gesprochen hast. Aber der kleine Ausflug zu GDPdU war auch ganz nett. Übrigens merken sich die Betroffenen diese absurde "Abkürzung" aus dem Finanzwesen mit der Eselsbrücke "Gib dem Prüfer deine Unterlagen". :lol:

Tatsächlich wusste ich von dem Zusammenhang bzw. der Problematik mit dem SVERWEIS im Fall der Änderung der Ausgangsdaten.

Um es dir leichter zu machen, hier meine Selbsteinschätzung:

Formeln in Tabellen verwende ich schon seit vielen Jahren. Alle, die ich selbst hineingeschrieben habe, habe ich glaube ich auch in allen ihren Konsequenzen verstanden.

Bei Makros sieht das ganz anders aus. Da kreise ich seit Jahren drumherum, und erst mit diesem Projekt habe ich angefangen, mich wirklich damit zu beschäftigen. Einiges von dem, was in den Makros auftaucht, habe ich vor zwei Wochen noch zu weniger als 50% verstanden, manches gar nicht.
Ich habe die Makros mit Copy and Paste und mit Trial and Error erstellt. Und ich war jedes Mal selbst überrascht, wenn etwas geklappt hat.
Daher war/ist da ja auch so viel unsinniges Zeug drin.
OMG - habe ich viele Kalorien verbrannt, als du schriebst, ich solle das mal hochladen. :mrgreen:
Aber du hast jetzt schon sehr viel Licht ins Dunkel gebracht! :-D Respekt!

LG Julia
Wilhelm Busch: "Ein jeder Wunsch, wenn er erfüllt, kriegt augenblicklich Junge."
... ich glaub, der wär heutzutage Programmierer und nicht Schriftsteller.

Benutzeravatar
balu
********
Beiträge: 3497
Registriert: Fr, 24.08.2007 00:28
Wohnort: Warstein

Re: Erarbeitung eines "POS-Kassenbuchs"

Beitrag von balu » Mi, 14.12.2016 23:38

Hallo Julia,
Formeln in Tabellen verwende ich schon seit vielen Jahren.
Gut zu wissen, denn dadurch kann ich mir später einiges an Tipp-Arbeit ersparen.

Daher war/ist da ja auch so viel unsinniges Zeug drin.
Na ganz so schlimm ist es ja auch nicht. Du hast dir gedanken gemacht wie Du deine Idden am besten umsetzen kannst. Das man das eine oder andere besser, oder anders erledigen kann, ist doch ganz normal, und außerdem woher sollst Du das auch schon alles kennen können.

Einiges von dem, was in den Makros auftaucht, habe ich vor zwei Wochen noch zu weniger als 50% verstanden, manches gar nicht.
Denke blos nicht weil ich hier relativ viele Beiträge geschrieben habe (die Anzahl kannst Du ja selber nachschauen), das ich wer besonders bin. Oh nein, dem ist nicht so! Grad wenns um Makros geht, zähle ich mich selber zu den Fortgeschrittenen Anfängern. Ich weiss noch längst nicht alles und ich werde auch nicht alles verstehen werden, aber ich weiss das ich mit meinem Wissen schon mal etwas auf die Beine gestellt habe, was sich durchaus sehen lassen kann (wurde von meinem "Kunden" sehr hoch gelobt).

Ich hatte wohl mich mit einem ähnlichen Thema, was hier auch bald dran kommen wird, schon manchmal mit befasst beziehungsweise befassen müssen. Aber jetzt ist dies Thema doch etwas anders gelagert, und bis Dienstag abend wusste ich nicht so recht wie ich das am besten lösen kann. Bis das ich hier durch Forenbeiträge auf etwas gestoßen bin, welches ich anschließend durch "Trial & Error" so mir erarbeitet habe das es wie gewünscht funktioniert. Ich sage jetzt nur mal so als nebeninfo:

"Ersetze SVERWEIS durch etwas anderes im Makro."

Aber wie gesagt, dieser Punkt, oder meinetwegen auch Thema, kommt etwas später dran. Und dann werde ich auch mehr dazu erklären und beschreiben.


Doch nun wird ernsthaft gearbeitet. :?

Und die Arbeit fängt mit ein paar Grundlegenden Informationen an, die den Umgang mit bestimten Dingen erleichtern und oder übersichtlicher machen sollen.

Fangen wir mit der Variablen deklaration an.
Im anderen Thread hatte ich dir ja schon ein paar davon vorgegeben. Wobei das dort nur ein "Schnellschuß" war, hier noch mal zur Verdeutlichung.

Code: Alles auswählen

Dim oArtikelnummer_Artikel as Object
Jetzt nehme ich mir zumindest etwas mehr Zeit für diesen Punkt.

Also warum habe ich den Variablennamen so benannt wie zu sehen ist?

Einerseits weil er so Eindeutig zuzuornen ist (Artikelnummer_Artikel), aber anderseits weil er noch eine bestimmte Aussage beinhaltet. Und diese Aussage lautet:

"Es handelt sich um ein Object"

Nein! Damit meine ich jetzt nicht das as Object, sondern das kleine o am Wortanfang oArtikelnummer_Artikel. Das as Object sehen wir nur jetzt bei der deklaration, aber später beim weiteren Programmieren nicht mehr. Und deshalb ist es hilfreich, wenn man den Typ der Variable auch schon vor dem eigentlichen Variablennamen später identifizieren kann.


Aber ist das denn sooo wichtig und ein Gesetzt?

Nein, es ist weder das eine noch das andere.
ABER
beim weiteren programmieren ist das schon sehr hilfreich, und anderseits können damit bestimmte Probleme umgangen oder Fehler vermieden werden.

Hilfreich:
Ein Objekt hat mehrere Eigenschaften, die nach beziehungsweise 'unter' dem Objekt zu finden sind.
Ich werde wohl nicht nur jetzt, sondern im weiteren Verlauf des Threads hier wohl öfters mal den Vergleich mit einem Haus anstellen.

Also das Objekt ist ein Haus. Und ein Haus hat einerseits viele Räume/Zimmer, die unterschiedlich gebaut und ausgestattet seien können, und anderseits hat auch das Haus ein Äußeres aussehen.

Wenn man also nun weiss, das es sich um ein Haus handelt, dann weiß man das man da noch viel mehr Informationen herausholen kann.
Beispiel:
Unterm Dach befindet sich eine kleine Wohnung die anders aussieht, als die übrigen Zimmer.
Hier sind 3 wichtige Informationen; Unterm Dach, anders aussieht, übrige Zimmer.
Unterm Dach ist eine Zelladresse wie z.B. A5, und aussehen ist zum Beispiel der Zellhintergrund. Und übrige Zimmer sind halt andere Zelladressen wie z.B. B99.


Probleme umgehen:
Vereinfacht ausgedrückt, es ist nicht gut wenn man einmal sagt,

Code: Alles auswählen

Dim Flasche as Object
und etwas später, wo man nicht mehr an den vergeben Variablennamen denkt, folgendes sagt.

Code: Alles auswählen

Dim Flasche as String
Okay, es kann durchaus wegen so etwa zu einer Fehlermelung vom Programm kommen. Aber es war ja jetzt nur mal etwas überspitzt dargestellt, obwohl so was auch schon mal ungewollt vorkommen kann.


Fehler vermeiden:
Und das ist ein extrem wichtiger Punkt. Der kann sich eventuell sehr schnell bemerkbar machen, oder vielleicht unter Umständen erst etwas später.

Es ist z.B. absolut VERBOTEN "Funktionsnamen" {Funktion, Anweisung} als Variablennamen zu verwenden. Also

Code: Alles auswählen

Dim Time as Object
geht schief. Das Office wird dies mit einer Fehlermeldung anmäääckern.
Umgehen könnte man dies z.B. durch

Code: Alles auswählen

Dim oTime as Object
jedoch ist sicherheitshalber auch davon abzusehen. Am besten, wenn irgendwie möglich, ruhig lange Wörter nehmen die z.B. einen Unterstrich beinhalten (oArtikelnummer_Artikel), oder eine andere Schreibweise aufweisen wie z.B. oArtikelNummerArtikel. Und es darf auch ruhig in deutsch geschrieben werden.


Okay, so viel zum "Object".
Kommen wir nun zu anderen Variablentypen.

Code: Alles auswählen

Dim End_Row as integer, ID as Integer, RowIndex as integer, End_Row as integer
Wirst Du auch noch in 2 Jahren bei einem Blick weit hinten im Makro-Code wissen was z.B. ID für ein Variablentyp ist?
Wie schon erwähnt, sieht man den Variablentyp nur jetzt am Makroanfang, aber weiter hinten kann man ihn schon wieder vergessen haben, und deshalb empfehle ich zumindest folgendes.
Den wichtigsten Variablennamen den Variablentyp voranzustellen. Dazu muss man sich ja eigentlich nur folgendes merken.
o = Object
i = Integer
s = String
l = Long
a = Array
v = Variant
...

Und dadurch würden dann jetzt die eben gezeigten Variablen so aussehen.

Code: Alles auswählen

Dim iEnd_Row as integer, iID as Integer, iRowIndex as integer
Sollte es vorkommen das eine "Zahlen-Variable" nicht mit INTEGER deklariert werden kann, weil sie durchaus größer als 32767 sein kann, und das als Ganzzahl also ohne Nachkommastelle, dann nimmt man sich natürlich einen anderen Variablen-Typ wie z.B. Long Integer.

Code: Alles auswählen

Dim lGrosseZahl as Long
Während man aus einem oHaus noch weitere, tiefer liegende Informationen auslesen kann - {später mehr dazu} - , geht das z.B. bei iKleineZahl nicht mehr, Ende der "Fahnenstange".

Jetzt muss ich aber noch mal zu dem Punkt Probleme umgehen zurück kommen, weil mir in deiner Datei ein Sonderfall aufgefallen ist. Der für dich anfänglich wohl verständlich ist, aber wohl vielleicht irgendwann einmal zu Problemen führen kann. Ich habe es jedoch noch nicht durchtesten können.

Um was geht es denn genau?

Ganz einfach, um das hier.

Code: Alles auswählen

Dim Val_Rabatt as Single, Val_EinnahmeAstra as Single
Okay, ich ersehe daraus das Du dir gedacht hast:

"Nehme ich halt Val, als Abkürzung für Value."

Tja, das dumme ist nur, das VAL eine fest vorgegebene FUNKTION ist. Und nein, ich werde jetzt an dieser Stelle nichts weiteres zu der Funktion sagen, das sollst Du jetzt selber herausfinden. Das hat auch den Sinn, das Du dadurch einen kleinen "Handhabungs-Trick" kennen lernst.

- Gehe in das Modul *Artikel*
- Suche die eben gezeigte DIM-Zeile
- Setze den Text-Cursor genau links vor das V von Val, oder probiers mit Text-Cursor in Val
- Drücke nun die Taste F1

Normalerweise sollte sich jetzt das Hilfe-Fenster von LO öffnen und dir etwas zu Val zeigen.

So, das bedeutet für dich, das Du eine vorgegebene Funktion als "Vorname" für einen Variablennamen vergeben hast. Und bis jetzt scheint es auch so, das wohl noch nix schlimmes passiert ist.
Aber darauf verlassen würde ich mich auf gar keinen Fall, denn Probleme können deswegen entstehen, oder auch nicht. Jedoch "Russisch-Roulett" spielen muss nicht sein.


Dieses Problem muss jetzt natürlich beseitigt werden. Das dumme an der Sache ist jetzt nur, das die Abkürzung s schon für String "verplant" wurde, auch wenn das nicht als in Stein gemeißeltes Gesetz anzusehen ist. Also was könnte man da machen, damit man auch anderer Stelle erkennen kann das es sich um eine Variable vom Typ Singel handelt?

Ich muss gestehen, das mir im moment keine passende Lösung einfällt die aus einem einzigen Buchstaben, außer s, besteht und auf den Variablen Typ Singel hinweist.
Mein Vorschlag wäre jetzt folgender.

Code: Alles auswählen

Dim sgRabatt as Single, sgEinnahmeAstra as Single
Nicht schön und elegant, aber immerhin ein Kompromiss.


Puuuh!
Viel Text.

Deine jetzige "Hausaufgabe" besteht darin, das Du die Variablen deklaration überarbeitest, Anregungen habe ich ja gegeben, anschließend die Variablen defenition änderst und natürlich die angewendeten Variablen auch dementsprechend abänderst. Und so nebenbei wendest Du mal zum üben für dich hin und wider den aufgeführten "Handhabungs-Trick" an. Man kann auch einfach F1 aufrufen und den gewünschten Suchbegriff direkt eingeben, aber manchmal ist diser Trick einfach sicherer und schneller.

Die geänderte Datei hängst Du beim nächsten mal hier an. Und dann nehmen wir uns ein anders Thema vor. Es sei denn Du hast dann noch Fragen zu der Variablen deklaration, dann werden wir uns dieser annehmen.



Schluß für Heute? :roll:
Ja! Soll erstmal reichen. ;-)



Gruß
balu
Sei öfter mal ein Faultier, sag öfter mal "Ach was!" Dann kriegst du keinen Herzinfarkt, und hast ne menge Spass.

wehr rächtschraipfähler findet khan si behalden :D

Stephan
********
Beiträge: 9681
Registriert: Mi, 30.06.2004 19:36
Wohnort: nahe Berlin

Re: Erarbeitung eines "POS-Kassenbuchs"

Beitrag von Stephan » Sa, 17.12.2016 09:38

Das ist wahr. Jetzt muss ich mal sagen, dass ich gar nicht an dem Tresen arbeite. Ich bin natürlich Frau Büro. Ich kann mir nur dann die Nächte um die Ohren schlagen, wenn ich einen Bildschirm vor der Nase habe. ;-)
Natürlich habe ich versucht, allen, die am Tresen arbeiten, eine solche Lösung schmackhaft zu machen. Man hat mir aber so lange verklickert, dass das nicht praktisch sei, bis ich mich hier im Forum wiedergefunden habe.
Aber es gab noch einen anderen Grund: Man zahlt immer für Features mit, die man nicht braucht, und es fehlen andere Dinge, die man gerne hätte:

Z.B. gibt es glaube ich keine Kasse, bei der man unbezahlte Getränke vor der Endabrechnung für später als unbezahlten Deckel auslagern kann. Es liegt nämlich in der Natur einer solchen Kneipe, dass die Gäste mehr trinken, als sie Geld dabei haben; das kommt täglich vor. Dann beginnt vor der Endabrechnug das Stornieren und es wird wieder ein Deckel auf einem Zettel gemacht.
Ein EC-Cash wäre eine Lösung. Auch eine Lösung wäre ein System, bei dem Kunden sich ein positives Konto durch Vorab-Einzahlung anlegen können, das gibt es.

Dies ist aber nicht das einzige Feature, was ein Kassensystem bei der schon genannten Summe haben sollte, und die beiden genannten Lösungen finden wir nicht optimal.
Letzten Endes läuft es darauf hinaus, dass wir wohl den Anspruch haben, dass unser Kassensystem explizit auf unsere Wünsche zugeschnitten sein soll und dass es das natürlich nicht gibt, außer man macht es selbst.
Bloß als kurze Reaktion, damit dieser Gedankenstrang abgeschlossen ist:

Mein grundlegender Gedanke war von Anfang an, das die Servierkräfte kleine Tablets haben müssten (keine Ahnung wie das heißt, aber ich meine Tabletts die man mit einer Hand halten kann ähnlich wie große Smartphones) und dort mittels Touch-Bedienung und auf dem Tablet-Monitor schreibend dass Programm bedienen. Parallel könnte hinter dem Thresen ein großer Monitor existieren für die die lieber damit arbeiten.

Das sind alles zunächst Hardwarefragen mit denen mich mich nicht sonderlich auskenne, nur weiß ich ja das solche Dinge heutzutage eher nicht teuer sind zumal eure Rechenleistungsanforderungen klein wären.

Das waren die Gedanken die mir im Kopf kreisten.


Gruß
Stephan

Benutzeravatar
Julia NuN
**
Beiträge: 37
Registriert: Mo, 07.11.2016 14:57

Re: Erarbeitung eines "POS-Kassenbuchs"

Beitrag von Julia NuN » Fr, 23.12.2016 17:06

Hallo balu,

puuuh, Adventskranz grad noch rechtzeitig fertig. Direkt mit 4 Kerzen drauf angesteckt - ist ja auch immer so unschön, wenn die alle unterschiedlich weit runtergebrannt sind.
Den Weihnachtsbaum hol ich mir dann, wenn es die umsonst an der Straße gibt. :-P
Dim iEnd_Row as integer, iID as Integer, iRowIndex as integer
Alles klar, deine Änderungsvorschläge habe ich so weit umgesetzt.

Bevor ich das jetzt aber hochlade, hätte ich noch eine Verständnisfrage:
Was muss ich eigentlich alles "dimmen"?

Ich frage das deshalb, weil es ja in meinen Subs selbst ja auch noch wieder Definitionen gibt.
Z.B. habe ich da noch so etwas drin:

Code: Alles auswählen

	Cell_ID = mySheet.getCellRangeByName("A9")
	iID = Cell_ID.value
	Val_Artikelnummer = oArtikelnummer_Artikel.Value()
	Val_Anzahl = oAnzahl_Artikel.Value()
	sgRabatt = oRabatt_Artikel.Value()
Nachdem wir "Val_Rabatt" und dem "Val_EinnahmeAstra" umgewandelt haben in "sgRabatt" und "sgEinnahmeAstra" würde ich denken, dass man dann "Val_Artikelnumer" und "Val_Anzahl" auch noch ändern sollte.
Aber diese beiden wurden vorher nicht gedimmt. Ich kann die ja jetzt nicht einfach in "iArtikelnummer" und "iAnzahl" umbenennen. Das würde ja eine Dimmung suggerieren, die nicht stattgefunden hat. Oder nenne ich die dann einfach nur "Artikelnummer" und "Anzahl"?
:? (<-- so unglücklich, wie der verwirrte Smiley aussieht, bin ich gar nicht - nur etwas verwirrt halt)

LG Julia
Wilhelm Busch: "Ein jeder Wunsch, wenn er erfüllt, kriegt augenblicklich Junge."
... ich glaub, der wär heutzutage Programmierer und nicht Schriftsteller.

Benutzeravatar
balu
********
Beiträge: 3497
Registriert: Fr, 24.08.2007 00:28
Wohnort: Warstein

Re: Erarbeitung eines "POS-Kassenbuchs"

Beitrag von balu » Fr, 23.12.2016 20:25

Hallo Julia,
Was muss ich eigentlich alles "dimmen"?
Eine wirklich sehr gute Frage.
Also Du musst langsam von hell auf dunkel dim.... uppsssi, falscher Film. :-)

Und wegen dieser Frage kann man wahrlich und tatsächlich wahre Romane schreiben. Kein Scherz.

DIM ist ja eine Variablen deklaration, die z.B. ein Objekt oder einen String (Text) aufnehmen kann, wenn diese Variable anschließend defeniert wird.

Es gibt ja nur 2 "Orte" wo man etwas *DIMMEN* kann.

a)
Einmal am Anfang eines Moduls, wie ja schon geschehen.

b)
Innerhalb einer Sub.

Deklariert man wie a), dann kann man wohl in der ersten Sub die direkt an die deklaration folgt und ausgeführt wird, eine Variable defenieren. Und hat mann mehrere Module mit vielen einzelnen Subs und ruft von da aus die defenierte Variable auf, so hat man auch Zugriff auf sie. Das heißt, das selbst nach verlassen der ersten ausgeführten Sub in irgendeinem anderen Modul und Sub die Variable noch existiert.

Deklariert man wie b), dann kann man nur in dieser Sub mit der Variablen arbeiten. Außerhalb dieser Sub existiert die Variable nicht.

Methode a) wird auch eine Öffentliche deklaration genannt.
Methode b) ist eine Lokale deklaration.

Es kommt jetzt auf das Makro selber darauf an, was man wo und wie deklariert. Und man kann auch problemlos beide Methoden kombinieren, aber die Variablen dürfen dabei nicht identisch sein. Soll heißen, wird *Lass_Es_endlich_schneien* Öffentlich deklariert, so darf es an anderer Stelle nicht Lokal deklariert werden.

Ich hatte schon ein bestimmtes Thema fast fertig geschrieben, der sich auch in gewisser Hinsicht mit diesen Punkt befasst. Dieser Beitrag kommt dann beim nächsten mal.


Du darfst aber die Begriffe und Bezeichnungen Deklaration und Definition nicht durcheinander werfen. Erst wird deklariert, und dann definiert. Eine Definition findet innerhalb einer Sub statt (auch wenn es spezielle Ausnahmen gibt die uns jetzt aber nicht betreffen), eine Deklaration wie vorhin beschrieben.

Man muss auch nicht unbedingt alles deklarieren und definieren. Der Zähler (i) einer Schleife

Code: Alles auswählen

For i = 0 to 10
	[tu was]
next i
gehört z.B. dazu. Es gibt auch noch andere Fälle wo das zutrifft, wenn z.B. ein Text in mehreren Schritten direkt hintereinander bearbeitet wird, und die Variable dazwischen nur an dieser Stelle nur kurzzeitig benötigt wird. Das aber nur so am Rande.

Das hier

Code: Alles auswählen

   Cell_ID = mySheet.getCellRangeByName("A9")
   iID = Cell_ID.value
macht man am besten ohne Zwischenschritt.
Und das würde dann so aussehen.

Code: Alles auswählen

   iID = mySheet.getCellRangeByName("A9").value   
dadurch erspart man sich einiges an Arbeit.

Da Du, wir, hier ja sehr viel mit Dialogen arbeiten, müssen die Variablen Öffentlich deklariert werden, da Du ja von einem Dialog zu einem anderen springst und dadurch aus einer Sub raus in eine andere Sub rein. Und wenn da die Variablen nicht richtig deklariert sind, geht der Inhalt beim hin und her springen verloren.

Ich hatte ja gesagt, Haus => Objekt.
Und wenn Du jetzt in einer Zelle wissen willst welche Farbe (CellBackColor) ein bestimmtes Zimmer ("M4") hat, dann geht das ja hiermit.

Code: Alles auswählen

Dim oSheet as Object
oSheet = thisComponent.Sheets.GetByName("31")
oSheet.getCellRangeByName("C1").string = oSheet.getCellRangeByName("M4").CellBackColor
In diesem Falle reicht die Deklaration nur vom oSheet.
Willst Du aber viel mehr infos z.B. aus der Zelle M4 auslesen, und dir dabei Arbeit ersparen, dann würde das so aussehen.

Code: Alles auswählen

Dim oSheet as Object
Dim oZelleM4 as Object

oSheet = thisComponent.Sheets.GetByName("31")
oZelleM4 = oSheet.getCellRangeByName("M4")

oSheet.getCellRangeByName("C1").string = oZelleM4.CellBackColor
oSheet.getCellRangeByName("C2").string = oZelleM4.AbsoluteName
oSheet.getCellRangeByName("C3").string = oZelleM4.CharFontName
oSheet.getCellRangeByName("C4").string = oZelleM4.String
Probier ruhig den Code mal in deiner Datei aus.

Nachdem wir "Val_Rabatt" und dem "Val_EinnahmeAstra" umgewandelt haben in "sgRabatt" und "sgEinnahmeAstra" würde ich denken, dass man dann "Val_Artikelnumer" und "Val_Anzahl" auch noch ändern sollte.
Ja, kannst Du machen. Aber überleg dir mal welchen Variablen-Typ Du dafür brauchst.
Wenn "Val_Artikelnumer" und "Val_Anzahl" jeweils nicht einen größeren Wert als 32767 aufnehmen werden, dann kannst Du ja INTEGER als Typ nehmen. Und sollte das eine oder andere größer werden als 32767, dann würde ja wohl LONG nahe liegen, vorausgesetzt es sind keine Komma-Zahlen.

Aber diese beiden wurden vorher nicht gedimmt. Ich kann die ja jetzt nicht einfach in "iArtikelnummer" und "iAnzahl" umbenennen.
Deklarieren, umbenenn, fertig.
Aus

Code: Alles auswählen

   Val_Artikelnummer = oArtikelnummer_Artikel.Value()
   Val_Anzahl = oAnzahl_Artikel.Value()
wird dann.

Code: Alles auswählen

Dim iArtikelnummer_Art as Integer, iAnzahl_Art as Integer
[....]
   iArtikelnummer_Art = oArtikelnummer_Artikel.Value()
   iAnzahl_Art = oAnzahl_Artikel.Value()
 

Oh je! Du hast meine Planung die ich mir schon vorgenommen hatte, jetzt aber gehörig durchzweidreinander gebracht. Hoffe nur das es dir ein wenig geholfen hat. Wenn nicht, dann gucki hier.

Den Weihnachtsbaum hol ich mir dann, wenn es die umsonst an der Straße gibt. :-P
Da hättest Du bei mir vor der Tür auf der Straße Null-Chance. Wir sind dauerrecylinger, jedes Jahr der gleiche Baum. :D



Gruß
balu
Sei öfter mal ein Faultier, sag öfter mal "Ach was!" Dann kriegst du keinen Herzinfarkt, und hast ne menge Spass.

wehr rächtschraipfähler findet khan si behalden :D

Benutzeravatar
Julia NuN
**
Beiträge: 37
Registriert: Mo, 07.11.2016 14:57

Re: Erarbeitung eines "POS-Kassenbuchs"

Beitrag von Julia NuN » Do, 29.12.2016 12:06

Hallo balu,

bei der Variablen-Definition habe ich sehr viele Veränderungen vorgenommen.

Ich habe folgende Elemente gedimmt:
a) alles, was in seiner Wortdefinition häufiger vorkommt
b) alles, was in Doppelbelegung auch in anderen Subs vorkam (z.B. Preis, Anzahl etc.)
c) alles, wo ich dachte, dass es ein Dach überm Kopf braucht (das sind z.B. die Rabatte und manchmal auch ein Preis - wenn er errechnet wird)

Einschub:
Ich hatte ursprünglich mal die Rabatte als Single ("sgRabatt_...") deklariert, weil ich dachte, dadurch könne ich festlegen, wie viele Nachkommastellen die Zahl haben soll.
Aber das funktioniert so offenbar nicht. Das Luxusproblem äußert sich eigentlich nur in der MsgBox, die aufpoppt, wenn man „Verkauf ganzer Flaschen“ eingibt (Testwerte: Nr. 167, Anzahl x, Füllmenge 1 Liter, Preis 50 €). Aber da gibt es bestimmt noch eine andere Lösung?

Es gibt noch unklare Stellen, z.B. die Formeln.
Die heißen alle "oFormula..." und sie waren ja trotzt ihres "o" im Namen nicht in der Deklaration. Ich habe das jetzt erstmal so gelassen und sie nicht noch in die Deklaration hineingenommen, weil es ja auch so funktioniert. Vielleicht machen wir das "o" einfach weg?


Nicht gedimmt habe ich, was nur kurzfristig verwendet wird.

Alle Elemente habe jetzt eine Endung, die sich auf das Thema des Subs/Dialogs bezieht:
"..._Art" für Modul "Artikel"
"..._PreisEingabe" für "Dlg_EP" in den Modulen "Artikel" und "Artikel_Korrektur"
"..._Korr" für Modul "Artikel_Korrektur"
"..._IDEingabe" für "Dlg_ID" in Modul "Artikel_Korrektur"
"..._Fl" für Modul "Flaschenverkauf"
"..._Ki" für Modul "Kiste_Astra"

Bei folgenden Elementen habe ich eine Ausnahme gemacht und ihnen keine Endung gegeben:
- Elemente, die in allen Subs gleich sind. Das betrifft z.B. iID und iEnd_Row, was immer denselben Wert wiedergibt – egal welcher Sub.

Ich hoffe, ich habe das jetzt nicht überbearbeitet. So 100%ig war mir das mit der Deklaration und den Definitionen denn doch nicht klar.

Bin gespannt, was jetzt kommt. :-D

LG Julia

Nachtrag: Da war noch ein Fehler in der Datei, der die einfache Artikeleingabe verhinderte. Daher habe ich sie hier unter gleichem Namen wie zuvor noch einmal hochgeladen, s.u.
Dateianhänge
POS_Kassenbuch_Forum_4.1.ods
(50.28 KiB) 18-mal heruntergeladen
Zuletzt geändert von Julia NuN am Do, 29.12.2016 13:10, insgesamt 1-mal geändert.
Wilhelm Busch: "Ein jeder Wunsch, wenn er erfüllt, kriegt augenblicklich Junge."
... ich glaub, der wär heutzutage Programmierer und nicht Schriftsteller.

Benutzeravatar
Julia NuN
**
Beiträge: 37
Registriert: Mo, 07.11.2016 14:57

Re: Erarbeitung eines "POS-Kassenbuchs"

Beitrag von Julia NuN » Do, 29.12.2016 12:41

Ich muss mich mal direkt selbst korrigieren:
c) alles, wo ich dachte, dass es ein Dach überm Kopf braucht (das sind z.B. die Rabatte und manchmal auch ein Preis - wenn er errechnet wird)
Das mit dem Dach ist natürlich nach unserer Definition falsch. Schließlich sind die Objekte das "Haus" und "sgRabatt_..." wäre dann "Ende der Fahnenstange" - richtig?

Nur damit du mir das nicht noch einmal erklären musst...
Wilhelm Busch: "Ein jeder Wunsch, wenn er erfüllt, kriegt augenblicklich Junge."
... ich glaub, der wär heutzutage Programmierer und nicht Schriftsteller.

Benutzeravatar
balu
********
Beiträge: 3497
Registriert: Fr, 24.08.2007 00:28
Wohnort: Warstein

Re: Erarbeitung eines "POS-Kassenbuchs"

Beitrag von balu » Do, 29.12.2016 18:34

Hallo Julia,

heute mach ich nicht mehr viel was, deshalb nur mal auf die schnelle etwas allgemeines.
Ich hoffe, ich habe das jetzt nicht überbearbeitet. So 100%ig war mir das mit der Deklaration und den Definitionen denn doch nicht klar.
Das Thema Variablen allgemein ist ja wirklich wie schon erwähnt ein sehr großes und Umfangreiches Thema. Da denkt man das man endlich alles Begriffen hat, und eh man sichs versieht stolpert man über ein määärkwüüürzikes Problem, grad dann wenn es mit Dialogen verbunden ist, kann ich ein Liedchen von singen. Und deshalb muss und werde ich mir deine Änderungen in Ruhe durchlesen und durcharbeiten. Und bei meiner nächsten Antwort werde ich dann näher darauf eingehen.

Einschub:
Ich hatte ursprünglich mal die Rabatte als Single ("sgRabatt_...") deklariert, weil ich dachte, dadurch könne ich festlegen, wie viele Nachkommastellen die Zahl haben soll.
Aber das funktioniert so offenbar nicht. [...] Aber da gibt es bestimmt noch eine andere Lösung?
Der Typ Single ist ja auch richtig, da damit Nachkommastellen verarbeitet werden können. Nur wird dadurch nicht die Anzahl an Nachkommastellen beeinflußt, wie Du selber schon festgestellt hast. Dafür gibt es extra eine Funktion mit den Namen: FORMAT
Schau mal in deine Online-Hilfe (F1) danach. Da ist das eigentlich recht gut erklärt.



Gruß
balu
Sei öfter mal ein Faultier, sag öfter mal "Ach was!" Dann kriegst du keinen Herzinfarkt, und hast ne menge Spass.

wehr rächtschraipfähler findet khan si behalden :D

Benutzeravatar
balu
********
Beiträge: 3497
Registriert: Fr, 24.08.2007 00:28
Wohnort: Warstein

Re: Erarbeitung eines "POS-Kassenbuchs"

Beitrag von balu » Do, 29.12.2016 21:52

So, habe doch noch etwas Zeit erübrigt.

Also, wir befinden uns im Tabellenblatt "Artikel".

Code: Alles auswählen

oFormulaText_Art = "=VLOOKUP(D" & iEnd_Row & ";Preisliste;2;0)"
Das ist kein Objekt, sondern ein String!

Grundsätzlich kann man bei so etwas sagen:
So bald einem Variablennamen etwas in doppelten Anführungszeichen (")zugeordnet wird, handelt es sich um einen String. Und in folge dessen wäre das so rum besser.

Code: Alles auswählen

sFormulaText_Art = "=VLOOKUP(D" & iEnd_Row & ";Preisliste;2;0)"
 
Achtung!
Ich springe jetzt mal kurzzeitig von einem Themenpunkt zum anderen hin und her, weil es jetzt sehr gut passt. Hoffe aber das Du nicht all zu sehr durcheinander kommst.

Du willst selbst erstellte Formeln in das Tabellenblatt schreiben lassen, aber warum sprichst Du denn nicht deutsch?
Dumme Frage, ich weiß.
Weil Du es wohl nicht anders kennst. Und deshalb mein Vorschlag.
Anstatt

Code: Alles auswählen

sFormulaText_Art = "=VLOOKUP(D" & iEnd_Row & ";Preisliste;2;0)"
[...]
mySheet.getCellRangeByName("B" & iEnd_Row).Formula = oFormulaText_Art
nimm mal das hier.

Code: Alles auswählen

sFormulaText_Art = "=SVERWEIS(D" & iEnd_Row & ";Preisliste;2;0)"
[...]
mySheet.getCellRangeByName("B" & iEnd_Row).FormulaLocal = SFormulaText_Art
Durch .FormulaLocal = wird die lokalisierte Spracheinstellung genommen. Das heißt, wenn dein System auf deutsch eingestellt ist, kannst Du die "deutschen" Funktionsnamen wie z.B. SVERWEIS, WENN, ODER etc. nehmen. Du brauchst also nicht erst nachzuschauen was SVERWEIS auf english heißt und das dann in deine Formel im Makro eintragen, sondern Du nimmst gleich den deutschen Namen dafür.

Sollte dir aber das englische im Makro besser gefallen, dann kannst Du bei .Formula = bleiben, also so wie gehabt.

Das Du in einem getrennten Block erst die Formeln den Variablen zuordnest, ist klar und verständlich, weil das übersichtlicher und besser zum Lesen ist.
Aber das hier

Code: Alles auswählen

	iArtikelnummer_Art = oArtikelnummer_Artikel.Value()
	sgAnzahl_Art = oAnzahl_Artikel.Value()
	sgRabatt_Art = oRabatt_Artikel.Value()
	
	mySheet.getCellRangeByName("A" & iEnd_Row).Value = iID + 1
	mySheet.getCellRangeByName("B" & iEnd_Row).Formula = oFormulaText_Art
	mySheet.getCellRangeByName("D" & iEnd_Row).Value = iArtikelnummer_Art	
	mySheet.getCellRangeByName("E" & iEnd_Row).Value = sgAnzahl_Art
	mySheet.getCellRangeByName("F" & iEnd_Row).Formula = oFormulaEinnahme_Art
	mySheet.getCellRangeByName("G" & iEnd_Row).Formula = oFormulaEPRabatt_Art
	mySheet.getCellRangeByName("I" & iEnd_Row).Value = sgRabatt_Art
	mySheet.getCellRangeByName("J" & iEnd_Row).Formula = oFormulaRabattArt_Art
	mySheet.getCellRangeByName("K" & iEnd_Row).Formula = oFormulaMindEinnahme_Art
kannst Du wirklich zusammen raffen, zu das hier.

Code: Alles auswählen

    iArtikelnummer_Art = oArtikelnummer_Artikel.Value()
' Die folgenden 2 Zeilen kannst Du löschen.'
'    sgAnzahl_Art = oAnzahl_Artikel.Value()'
'    sgRabatt_Art = oRabatt_Artikel.Value()'
    
    mySheet.getCellRangeByName("A" & iEnd_Row).Value = iID + 1
    mySheet.getCellRangeByName("B" & iEnd_Row).Formula = oFormulaText_Art
    mySheet.getCellRangeByName("D" & iEnd_Row).Value = iArtikelnummer_Art
    mySheet.getCellRangeByName("E" & iEnd_Row).Value = oAnzahl_Artikel.Value()' jetzt neu'
    mySheet.getCellRangeByName("F" & iEnd_Row).Formula = oFormulaEinnahme_Art
    mySheet.getCellRangeByName("G" & iEnd_Row).Formula = oFormulaEPRabatt_Art
    mySheet.getCellRangeByName("I" & iEnd_Row).Value = oRabatt_Artikel.Value()' jetzt neu'
    mySheet.getCellRangeByName("J" & iEnd_Row).Formula = oFormulaRabattArt_Art
    mySheet.getCellRangeByName("K" & iEnd_Row).Formula = oFormulaMindEinnahme_Art
Dadurch ersparst Du dir die deklarationen und defenitionen der Variablen sgAnzahl_Art und sgRabatt_Art.

Allgemein dazu gesagt.
Willst Du z.B. aus einem Textfeld in einem Dialog etwas auslesen und das direkt in eine Zelle in einem Tabellenblatt schreiben, so kannst Du direkt den Inhalt des dementsprechenden Elements auslesen und in die Zelle schreiben lassen. Der Umweg über erst noch eine Variable zu erstellen um diese zu verarbeiten, kannst Du dir ersparen.

Da Du ja mehrfach dies System mit einer Zwischenvariablen verwendest, solltest Du jetzt daher gehen und das dementsprechend nach dem gezeigten Beispiel ändern.


Ich weiß wie schwer das alles zu verdauen ist, wenns um Variablen geht. Und dabei ist das jetzt hier alles recht harmlos.


Weiter zum nächsten Variablen Schritt.

Du arbeitest ja aus verständlichen Gründen viel mit .activesheet

Code: Alles auswählen

mySheet = thiscomponent.getcurrentcontroller.activesheet
aber dann mach doch bitte folgendes daraus.

Code: Alles auswählen

oAktuellesBlatt = thiscomponent.getcurrentcontroller.activesheet
Und da wir grad bei "Sheet" sind, noch folgendes.
In den Modulen *Flaschenverkauf* und *Kiste_Astra* hast Du jeweils das Tabellenblatt "Preise" defeniert. Wahrscheinlich hast Du das noch nicht richtig geändert, da wir diesen Punkt schon weiter vorne hatten.
Also,

Code: Alles auswählen

Dim oSheet as Objekt
[...]
oSheet = thisComponent.Sheets.GetByName("Preise")
"gedimmt" ;-) war ja so weit ok. Nur sollte die defenition der Variable im Modul *Artikel* in der Sub Dlg_Neuer_Artikel erfolgen, und nicht in den anderen Modulen und anderen Subs.
Und deshalb machst Du jetzt folgende Änderungen.
In dem eben genanten Modul ein neuer Name für das Blatt deklarieren.

Code: Alles auswählen

Dim oBlattPreise as Object
Also nicht mehr oSheet.
Und nun in der eben genannten Sub diese Zeile noch eintragen.

Code: Alles auswählen

oBlattPreise = thisComponent.Sheets.GetByName("Preise")
 
Wo genau dort, das überlass ich dir. Jedoch muss dies noch vor Dlg_Artikel.execute geschehen.

Anschließend löscht Du in den Modulen *Flaschenverkauf* und *Kiste_Astra* die defenition des Blattes "Preise".
Das anschließend natürlich überall "oSheet" durch "oBlattPreise" ersetzt werden muss, ist ja wohl selbstredend. ;-)

Ich denke mir das Du hiermit doch so einiges zu tun hast. Und wenn Du das alles geändert hast, wird auf spezielle Art und Weise auf- und umgeräumt. Womit wir dann bei meinem vorbereitetem neuen Thema wären. :-)



Gruß
balu
Sei öfter mal ein Faultier, sag öfter mal "Ach was!" Dann kriegst du keinen Herzinfarkt, und hast ne menge Spass.

wehr rächtschraipfähler findet khan si behalden :D

Benutzeravatar
Julia NuN
**
Beiträge: 37
Registriert: Mo, 07.11.2016 14:57

Re: Erarbeitung eines "POS-Kassenbuchs"

Beitrag von Julia NuN » Mo, 02.01.2017 18:04

Hallo balu,

bei mir überschneidet sich jetzt so Einiges:
Ich bin gerade dabei, die Tabelle wegen des Jahreswechsels noch einmal für den Kneipengebrauch überarbeiten - das betrifft die Preise und noch ein paar neue Optionen.
Jetzt war es mir zeitlich nicht möglich, schon deine neuen Punkte umzusetzen und für die neuen Sachen anzuwenden.

Daher bringe ich nun erstmal die neue Tabelle zum Laufen, damit in der Kneipe weiter gearbeitet werden kann und danach lade ich nochmal alles hoch mit den Neuheiten.

Ich wünsche gut gerutscht zu sein!

LG Julia
Wilhelm Busch: "Ein jeder Wunsch, wenn er erfüllt, kriegt augenblicklich Junge."
... ich glaub, der wär heutzutage Programmierer und nicht Schriftsteller.

Benutzeravatar
balu
********
Beiträge: 3497
Registriert: Fr, 24.08.2007 00:28
Wohnort: Warstein

Re: Erarbeitung eines "POS-Kassenbuchs"

Beitrag von balu » Mo, 02.01.2017 20:56

Hallo Julia,

alles kein Problem. Nimm dir ruhig die Zeit die Du brauchst.
Ein Jahreswechsel ist nicht immer nur ein Jahreswechsel.
Ich wünsche gut gerutscht zu sein!
:lol: Yep! Bin aber nicht ausgerutscht. Und selber?



Gruß
balu
Sei öfter mal ein Faultier, sag öfter mal "Ach was!" Dann kriegst du keinen Herzinfarkt, und hast ne menge Spass.

wehr rächtschraipfähler findet khan si behalden :D

Benutzeravatar
Julia NuN
**
Beiträge: 37
Registriert: Mo, 07.11.2016 14:57

Re: Erarbeitung eines "POS-Kassenbuchs"

Beitrag von Julia NuN » Di, 03.01.2017 19:54

oops, schon wieder doppelt, s.u....
Zuletzt geändert von Julia NuN am Di, 03.01.2017 19:57, insgesamt 1-mal geändert.
Wilhelm Busch: "Ein jeder Wunsch, wenn er erfüllt, kriegt augenblicklich Junge."
... ich glaub, der wär heutzutage Programmierer und nicht Schriftsteller.

Benutzeravatar
Julia NuN
**
Beiträge: 37
Registriert: Mo, 07.11.2016 14:57

Re: Erarbeitung eines "POS-Kassenbuchs"

Beitrag von Julia NuN » Di, 03.01.2017 19:56

Hey balu,
Yep! Bin aber nicht ausgerutscht. Und selber?
Sehr brav!

Ich hab den Jahreswechsel super mit backen, kochen und essen hinter mich gebracht.
Diesmal also kein Kater sondern Bauchschmerzen... irgendwas ist ja immer. :lol:

Ich hab dir ne Nachricht geschickt!

Für alle anderen am eigentlichen Thema Interessierten:
Es geht weiter - dauert bloß ein bisschen. :)

LG Julia
Wilhelm Busch: "Ein jeder Wunsch, wenn er erfüllt, kriegt augenblicklich Junge."
... ich glaub, der wär heutzutage Programmierer und nicht Schriftsteller.

Benutzeravatar
balu
********
Beiträge: 3497
Registriert: Fr, 24.08.2007 00:28
Wohnort: Warstein

Re: Erarbeitung eines "POS-Kassenbuchs"

Beitrag von balu » Mi, 04.01.2017 02:17

Moin moin Julia,
Diesmal also kein Kater sondern Bauchschmerzen... irgendwas ist ja immer. :lol:
Man-oh-man! Ich werd alt! Keine Miau-miau, und keine 2. Gehirn schmerzen. :)



Gruß
balu
Sei öfter mal ein Faultier, sag öfter mal "Ach was!" Dann kriegst du keinen Herzinfarkt, und hast ne menge Spass.

wehr rächtschraipfähler findet khan si behalden :D

Benutzeravatar
Julia NuN
**
Beiträge: 37
Registriert: Mo, 07.11.2016 14:57

Re: Erarbeitung eines "POS-Kassenbuchs"

Beitrag von Julia NuN » Sa, 07.01.2017 12:18

Hey balu,
Man-oh-man! Ich werd alt! Keine Miau-miau, und keine 2. Gehirn schmerzen. :)
Wie - weder Kopf- noch Bauchschmerzen?! Du brauchst dringend ein Laster! :P

Zum Stand der Dinge:
Mein Wissen erweitert sich gerade in ungünstigen Abständen. Sobald ich eine Veränderung/Verbesserung vorgenommen und in allen Modulen umgesetzt habe, fällt mir noch was besseres ein.

Aufgrund deines Hinweises vor einiger Zeit, besser die SVERWEISE im Makro berechnen zu lassen, fliegen jetzt alle Formeln aus dem Tabellenblatt.
Ein anderer Hintergrund ist die Tatsache, dass die Berechnungsformeln in der Tabelle das System verlangsamen, zumal wir auf einem Raspberry arbeiten.

Joa, und dann gibt es ja auch noch so einige andere Veränderungen seit meinem letzten Upload, weil für den Start des Systems ab Januar in der Kneipe noch einiges Neues gewünscht war...

Ich fürchte, du wirst das Kassenbuch nicht wiedererkennen.

Jetzt mache ich mich wieder an die Arbeit, damit ich schnellstmöglich was Greifbares hochladen kann.

LG Julia
Wilhelm Busch: "Ein jeder Wunsch, wenn er erfüllt, kriegt augenblicklich Junge."
... ich glaub, der wär heutzutage Programmierer und nicht Schriftsteller.

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast