[de-users] Draw_Füllung?
Hi, hab da ein Problem mit dem Programm Draw. Ich habe ein Dreieck, welches aus Rohren besteht. Dazu nutze ich für die Flachen: 1. Farbverlauf * Axial, 0°, 90°, 315°(Hypotenuse 45°) * Grün 7, Grau 9 Die beiden rechtwinkligen Schenkel sind einwandfrei, aber die 45°-Fläche erscheint nur Grün. Es erscheint so, dass im Hintergrund eine grössere Fläche angesprochen wird und nur der Zentrumsteil sichtbar wird. Wie kann ich das nun richtig hinkriegen? Leider kann ich das hier nicht visuell darstellen... Gruss Marino -- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] Automatisierung als Eingabehilfe
Hi Boris, darf ich dazu mal die Frage stellen, warum Du für diese Aufgabe nicht "Base" verwendest? Die Aufgabe ist je geradezu prädestiniert als Datenbank aufgesetzt zu werden. Es ist Augenfällig, dass ich immer wieder solche Dinge im Forum lese, aber praktisch niemand gibt den Rat, Buchhaltungs-Aufgaben in Base zu realisieren; warum nur? Diese sind ja einer Kalkulationstabelle dafür allemal vorzuziehen... (ich bin mir schon bewusst, dass es ein wenig Einarbeitsaufwand erfordert, das sollte aber nicht abschrecken, da durch die verknüpften Daten einer DB jede erdenkliche Abfrage gemacht werden kann) Gruss Marino Boris Kirkorowicz schrieb am 19.01.2020 um 17:00: Hallo, gerade bereite ich die Tabelle für mein Kassenbuch vor, und wie jedes Jahr sinne ich erneut über Vereinfachungen bei der Eingabe, Fehlerkontrollen u.ä. nach. Meine aktuelle Idee: Abhängig vom Rechnungsaussteller soll es eine Auswahl für ein anderes Feld geben, also so etwas wie eine variable Gültigkeitsprüfung. Zum Verständnis ein Beispiel: Die Wasserwerke schicken verschiedene Rechnungen, etwa Jahresabrechnungen (JA) und Abschlagsrechnungen (AB), und diese für Trinkwasser (TW), für Schmutzwasser (SW) und für Niederschlagswasser (NW). Zudem fällt für TW Umsatzsteuer i.H.v. 7% an, für SW und NW nicht. Sei in meiner Tabelle die Spalte F für den Rg-Aussteller, Spalte G für die Bezeichnung der Rechnung, Spalte I für den USt-Satz vorgesehen. Wenn ich nun etwa in Spalte F eintrage "Wasserwerke", möchte ich in Spalte G eine Auswahl haben zwischen JA TW JA SW JA NW AB TW AB SW AB NW und bei JA TW und AB TW in Spalte G die Werte 7% in Spalte I voreingetragen, sonst 0%. Trage ich dann in Spalte F etwa "Fernheizwerk" ein, soll es dann in Spalte G die Auswahl JA Fernwärme AB Fernwärme geben, belegt mit 19% USt. usw. Bei einfachen Gültigkeitsprüfungen habe ich mir bislang Benannte Bereiche erstellt, aus denen ich dann die Gültigkeiten bzw. Zuordnungen ausgelesen habe. Wie aber stelle ich es an, in Abhängigkeit von einem Wert / Inhalt einer Zelle einen jeweils anderen Bereich anzuziehen? Oder gibt es für diese Anwendung ein anderes, besser geeignetes Vorgehen? -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] Zeit Eingabe
Hallo Michael, Die lokalen Einstellungen haben damit nichts zu tun, da MM auch im Englischen wie im Deutschen für Monat und Minute gelten! Gruss Michael Höhne schrieb am 15.01.2020 um 13:17: Am Wed, 15 Jan 2020 10:34:50 + schrieb OoOHWHOoO : Wenn man CALC über das eindeutige Format "MM:SS" sagt, wie es eine Eingabe interpretieren soll, dann sollte CALC das auch tun. Oder ? Das Format ist ein _Anzeige_-Format! Du sagst Calc, wie er den Zelleninhalt _anzeigen_ soll. Es ist ja schon des öfteren erklärt worden, dass Calc keine Uhrzeit oder Datum speichert. In der Zelle wird eine _Zahl_ gespeichert: Die Vorkommastellen geben das Datum vor (Tage seit einem vorgegebenen Referenzdatum) und die Nachkommastellen ergeben dann die Zeit. So ist mit den Nachkommastellen 0,25 ein Viertel eines Tages und damit 6:00 angegeben. Mit dem Referenzdatum 30.12.1899 kommt man mit der Zahl 413,75 z.B. auf den 16.02.1901 (30.12.1899 + 413 Tage) und die Uhrzeit 18:00 (0,75 * 24). Welche Eingabe in einer Zelle nun exakt zu welcher _Zahl_ als Inhalt führt, dürfte mit diversen "intelligenten" Erkennungen im Zusammenhang mit den lokalen Einstellungen von Betriebssystem und LO selber zusammen hängen. Das ist ein eigenes Kapitel für sich. Gruß, Michael -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] Zeit Eingabe
Hall Ernst, Ernst Hügli schrieb am 15.01.2020 um 13:26: Hallo Marino Am 15.01.20 um 12:19 schrieb Marino Salvalaggio: Hallo, OoOHWHOoO schrieb am 15.01.2020 um 11:34: Und noch eine Möglichkeit: Format: MM:SS,00 Eingabe: 0:12,0 Anzeige: 00:12,00 Aber letztendlich bin ich schon der Meinung, dass da ein LO-BUG vorliegt. Wenn man CALC über das eindeutige Format "MM:SS" sagt, wie es eine Eingabe interpretieren soll, dann sollte CALC das auch tun. Oder ? Ich hatte anderer Orts schon mal darauf hingewiesen, dass Calc offensichtlich Monate und Minuten nicht eindeutig formatiert. So Funktioniert: mit jahren MM mit Monaten TT mit Tagen HH mit Stunden MM sollten Minuten sein => unter Zeit aber nicht mit Minuten, sondern wird in Datum transferiert und in Monaten ausgegeben SS Sekunden Warum man die Abkürzungen für Datum nicht in Grossbuchstaben und Zeit in Kleinbuchstaben hält kann ich wirklich nicht nachvollziehen. So muss Calk hier versagen! Marino Wieso bist Du der Meinung, Calc würde Minuten und Monate nicht eindeutig formatieren? Michael hat auf die interne Speicherung und die Anzeige als wesentlichen Unterschied hingewiesen. Und da kommt der User ins Spiel: Damit Calc erkennt, was Du genau mit der Eingabe meinst, musst Du richtig eingeben: Trennung mittels Doppelpunkt meint Zeit, also z.B. 2:12:00 meint 2 Stunden, 12 Minuten und 0 Sekunden. Daten hingegen werden durch einen simplen Punkt unterschieden: 15.1.2020 ist das heutige Datum. Und wenn die Calc-Zelle richtig formatiert ist, interpretiert Calc Deine Eingabe auch richtig (abhängig von den Grundeinstellungen, denn im angelsächsischen Bereich werden Daten z.B. anders formatiert als im kontinentalen Europa). Was Calc tatsächlich nicht schafft, ist, Deine Intention zu erkennen: Meinst Du jetzt eine Zeit oder ein Datum? Calc braucht dafür entweder eindeutige Eingaben oder eindeutige Formatierungen. Deine Gedanken lesen kann Calc nicht, wohl auch kein anderes Programm [?] ... Gruss Ernst Es geht hier nicht darum, wie Calc das im Hintergrund speichert, sondern darum wie Calc die Interpretation aus den Masken Ausführt. Wen ich eine Zelle Formatiere, Mache ich ja ein Fenster auf und finde unter der Rubrik Zahlen u.A. die Kategorien "Datum" und "Uhrzeit" Wähle ich da Uhrzeit und setze den Formartcode mit MM, und schliesse diesen. dann ist in Wirklichkeit aber Datum und Monat gesetzt. Schreibe ich hingegen :MM oder MM: so bleibt es eine Uhrzeit mit dem Nachteil,dass ich nun keine Glanzzahlen einsetzen kann, sondern den ":" an der gewählten Stelle einfügen muss. Bei allen anderen Abkürzungen ist das nicht notwendig, da diese eben eindeutig sind! Teste das mal in einer Tabelle, dann wirst Du erkennen was ich meine. Gruss Marino -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] Zeit Eingabe
Hallo, OoOHWHOoO schrieb am 15.01.2020 um 11:34: Und noch eine Möglichkeit: Format: MM:SS,00 Eingabe: 0:12,0 Anzeige: 00:12,00 Aber letztendlich bin ich schon der Meinung, dass da ein LO-BUG vorliegt. Wenn man CALC über das eindeutige Format "MM:SS" sagt, wie es eine Eingabe interpretieren soll, dann sollte CALC das auch tun. Oder ? Ich hatte anderer Orts schon mal darauf hingewiesen, dass Calc offensichtlich Monate und Minuten nicht eindeutig formatiert. So Funktioniert: mit jahren MM mit Monaten TT mit Tagen HH mit Stunden MM sollten Minuten sein => unter Zeit aber nicht mit Minuten, sondern wird in Datum transferiert und in Monaten ausgegeben SS Sekunden Warum man die Abkürzungen für Datum nicht in Grossbuchstaben und Zeit in Kleinbuchstaben hält kann ich wirklich nicht nachvollziehen. So muss Calk hier versagen! Marino Gruß Hans-Werner -- Originalnachricht -- -- ¦ ¦ --- -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] alte Dokumente unlesbar (Codierung?)
Hallo, Rainer schrieb am 05.01.2020 um 21:19: Hallo, Am Sun, 5 Jan 2020 20:03:11 +0100 schrieb Wolfgang Jäth : Gibt es eine Möglichkeit, entweder einzelne Dokumente oder (besser noch) ganze Verzeichnisse in einem Rutsch korrigieren zu lassen? Ideal wäre ein Tool, das unter Ubuntu gut läuft. Ich fürchte, nein. Eventuell kannst du was mit dem Microsoft Word Viewer ( https://www.chip.de/downoads/DOC-Datei-oeffnen_42813011.html ) retten, Seite wurde nicht gefunden. Ist vermutlich auch ein Windows-Programm, oder? Und ehrlich gesagt frage ich mich, ob sich so ein Aufwand wirklich lohnt. Haben denn diese alten Dateien noch mehr als rein emotionalen Wert? Ob der User seine Dateien für Kaffeesatz lesen nutzt, oder ob das eine für ihn wichtige Studienarbeit war, ist doch irrelevant!! Es geht hier einzig und alleine darum, dass unsere so hochgelobte Digitalisierung es offensichtlich mit sich bringt, dass alter Code; habe solches selber schon erleben müssen; mit schmerzhaften Verlusten einher geht. - Und warum: Ganz einfach weil bei vielen Applikation, die Programmierer sich nicht an ein einheitliches Codieren von Daten halten! Jeder denkt, dass seine Hinterlegung für den User ja nicht nachvollziehbar sein muss; wichtig nur, dass es für ihn Zweckmässig ist. Die Folgen solches Denken trägt dann ja der User.. Wirklich ein enormer Fortschritt für die Geschichtsforschung... ps. Wolfgang, haben wir nicht kürzlich in einem anderen Zusammenhang von Codierung und Daten-durchgängig gesprochen? Ja, sonst würde ich gleich die Finger davon lassen. Gegenfrage zur analogen Welt: Hast Du alles an älteren Papierdokumenten vernichtet? Nichts mehr dazwischen, was z.B. 20 Jahre alt ist und mehr, als nr emotionalen Wert hat? Viele Grüße Rainer -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: Solved: [de-users] Calc: Zeiten vereinfacht eingeben
Hallo Wolfgang, als 1. möchte ich hierzu bemerken, dass ich in Zukunft nicht mehr weiter zu diesem Thema schreiben werde; es sei denn, jemand hat eine direkte Frage an mich. Derjenige darf mich dann direkt ansprechen. Der Rahmen hier wird eindeutig gesprengt. Wolfgang Jäth schrieb am 29.12.2019 um 15:32: Am 29.12.2019 um 10:35 schrieb Marino Salvalaggio: *Alle* Daten, sogar Texte, werden intern binär abgelegt. Und Calc selbst kennt überhaupt nur 3 Datentypen, nämlich String aka Text, Integer und Gleitkomma aka Double. Jep, aber nur bedingt richtig "Wahrheitswert" (BOOL) hast Du unterschlagen... Nein; bool ist genauso nur ein Integerwert (0=falsch, alles andere=WAHR); probiers aus. Das ist dann in etwa das selbe, wie wenn ich für jeden einzelne Fahrgast einen Bus mit 60 Sitzplätzen auf die Reise schicke - wirklich sehr effizient! Kein Wunder,dass die Prozessoren immer schneller werden und am Ende die Berechnungswartezeit trotzdem nicht kürzer wird... Wenn das, was Du hier sagst richtig ist; das die Zeiten in Calc in Fliesskomma-Werten hinterlegt sind; dann werden bei gewissen Rechenoperationen unweigerlich Fehler auftrete. Tut es, ja. Allerdings so weit hinten, dass das nur sehr selten auf fällt. Aber gelegentlich tut es das; such mal im Archiv (siehe Footer) nach dem Thread "CALC: Uhrzeit wird beim Kopieren mit Maus falsch berechnet" vom 3.12.2019. Auch das ist nur bedingt richtig. Wenn man kurze Zeiten zuerst dividiert und erst anschliessend multipliziert, kann es schon es erheblichen Rundungsfehler führen... Für eben solches aber benutze ich z.B. Calc, da ich unter Anderem in der Netzfrequenzen die Abweich-Toleranz im Drehfeld in Winkel° berechnen muss... (Synchronisation von Generatoren) Nicht gerade das Gesuchte. In INT würde solches nie auftreten. Auf Leitsystemen mit Echtzeiteinträgen ist es Bedingung, dass die Zeitstempel kohärent sind! Ähm; dir ist aber schon bewusst, was das Wort "kohärent" wirklich bedeutet, oder? Im Zusammenhang mit Zeit sicherlich ein passender Begriff, wenn man Gleichtakt, Phasengleichheit darunter versteht... Meine Aussagen beruhen aber auf den Standard von den grundsätzlichen ANY_INT Datentypen. Und was bitte hat das mit Calc zu tun? In Calc *gibt* es das alles nicht, bzw. nur als Abbildung in eine der 3 möglichen Datentypen. Die Aufgliederung in BYTE ist darum zu berücksichtigen, weil die meisten seriellen Transportmittel; CAN, PROFIBUS, MODBUS, Ethernet; Byte-weise übertragen und die Speicher in Byte organisiert sind! Schon lange nicht mehr; sowohl die Übertragnung als auch die Speicherung. Die Speicherung innerhalb heutiger Hardware erfolgt fast ausschließlich 32-bitig oder 64-bitig, teilweise sogar schon 128-bitig; nur gnz selten ist noch uralte 16-bit-Hardware in Gebrauch; 8-bit-Hardware gips bestenfalls noch im Museum. Und /serielle/ Transportprotokolle wie die oben von dir aufgeführten heißen "seriell", weil sie die Bits einzeln, eines nach dem anderen, /hintereinander/ übertragen, und nicht byteweise aka 8 bit parallel. Ob diese Bits anschließend wieder zu 8-, 16-, 32-, 64- oder 128-bit Ganz-, Festpunkt- oder Fließkommazahlen oder Strings oder noch was anderes zusammen gesetzt werden, ist dem Protokoll völlig wurscht. Erzähl mir nun bitte über solche Protokolle keine Märchen... => C-Programm am Ende. Wie willst Du den ohne Byte-Staffelung ein Transkript von seriell litle- nach big-endian durchführen? Trotzdem muss ich mich wiederholen mit der Frage, was das alles mit Calc zu tun hat. Hint: Cals ist ein Tabellenkalkulationsprogramm, kein Transportprotokoll (und schon gar kein serielles). Die Frage ist immer noch die Selbe: Warum wurde der Zeitstempel bei Calc in eine REAL hinterlegt? Dar Programmiere muss doch einen triftigen Grund dafür gehabt haben... Wolfgang Das folgende hat nun tatsächlich gar nichts mit Calc zu tun, ausser dass die daraus resultierende Daten via OPC in eine Tabelle auf dem Server eingetragen und als Graphik ausgegeben werden. Das was ich hier einkopiert habe ist ein Konvertierungs-Funktionsblock, welcher in eine übergeordnete System-Programmierung eingebunden wird. Leider gibt es drei Konventionen für die serielle Übertragung die auf das im Empfänger genutzte Protokoll umgeschrieben werden muss; das Rad wird halt immer wieder mal neu erfunden. Ist leider nicht sehr gut lesbar, da der Code mit mehr Zeichen je Zeile aufgesetzt war. (*SOFTCONTROL: VERSION:4.00.21*) FUNCTION_BLOCK Cnv_LitleBigMixed_Endian (**) (**) (*GroupPath='POUs'*) VAR_INPUT xEn: BOOL:=FALSE; (*enable*) pModify: BOOL:=FALSE; (*start to modify*) siCnvTyp: SINT:=0; (*type of Convert 0 = 1 /1 Dut Copy no convert 1 = BigEnd <=> LtlEnd 2 = BigEnd <=> MxlEnd
Re: Solved: [de-users] Calc: Zeiten vereinfacht eingeben
Hi Admin04, Michael Höhne schrieb am 29.12.2019 um 11:12: Hallo Marino, Wenn das, was Du hier sagst richtig ist; das die Zeiten in Calc in Fliesskomma-Werten hinterlegt sind; dann werden bei gewissen Rechenoperationen unweigerlich Fehler auftrete. Nicht gerade das Gesuchte. In INT würde solches nie auftreten. Auf Leitsystemen mit Echtzeiteinträgen ist es Bedingung, dass die Zeitstempel kohärent sind! Gerade beim Abgleich von Letzt-wert, was in Leitebene als Bedingung für die Neuwert-Gültigkeit steht (DCP/IP Daten-Überholungen), eine absolute Bedingung. Somit kommt Calc als Tabelle für Datenhinterlegung für diesen Zweck nicht in Frage! In solchen Fällen müsstest du Zeitangaben in INT _codieren_. Es hält dich ja niemand davon ab, Zeiträume oder Zeitpunkte z.B. in Sekunden oder Millisekunden zu speichern. Im Falle eines Zeitpunktes müsstest du allerdings einen passenden Zeitpunkt als Nullpunkt festlegen. Du könntest den Zeitpunkt des Messbeginns (möglicherweise als String) in die Tabelle schreiben und diesem den Wert 0 (Millit-)Sekunden zuweisen. Alle weiteren Zeitwerte werden dann als INT-Wert bezüglich dieses Startwertes abgelegt. Das ist schon richtig und durchaus ausführbar und Zielführend. Nur möchte ich dazu bemerken, dass solches bekannt sein muss. Ich denke, dass die Wenigsten sich mit solchen Dingen beschäftigen und hinterfragen wie die Daten im Hintergrund tatsächlich manipuliert werden. Ich jedenfalls habe das bisher nie hinterfragt. So war mir auch gar nicht bewusst, dass die Zeit in Calc durch anwendung von FLOAT für hochdynamische Prozesse, oder für höhere Mathematik ungeeignet ist. Was mich wundert ist daher, warum man auf solch eine Idee überhaupt gekommen ist. Auf CPUs die Echtzeitverhalten mit Zeitstempel nutzen wird die Zeit von einem Zeitserver auf alle Teilnehmer übertragen und in den lokalen Rechnern wird immer in DINT bez. LINT hinterlegt! Jeder Datenpunkt welcher aus der Zukunft stammt wird direkt als falsch verworfen ist er älter als der Letzt-gültige Eintrag bleibt er unberücksichtigt! Das hat sich durchgängig als die sicherste Methode erwiesen. Mann stelle sich einmal das CERN vor, wenn deren Zeiten nicht sicher verifizierbar wären... Der wer? Meinst du etwa das Teil, mit dem eine Zeitreisemaschine gesteuert wird? Nein, das ist ein "Fluxkompensator" ;-) Admin04 -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] JRE nicht auffindbar
Marino Salvalaggio schrieb am 29.12.2019 um 10:48: Hallo Richard, vielen Dank für Deinen Link. Nach endlosen Versuchen mit Deinstallieren und reinstallieren von LobOf und Java, was alles nicht fruchtete, endlich mal ein Hinweis der das hielt was versprochen war! Gruss Marino Richard Kraut schrieb am 28.12.2019 um 21:28: ¦ ¦ ps. Merkwürdig an der Sache ist: (Dummerweise von mir nicht erkannt, das in der Zwischenzeit der LibOf-Download nachgezogen wurde und so die Systeme gar nicht identisch waren) Auf System 1 ist LibOf V-6.3.3.2(x64) und es findet sich unter: Extras/Optionen/Erweitert OracleCorporation/1.8.0_231 Speicherort: C:\Programme-Files\Java\jre1.8.0_231 Auf System 2 ist LibOf V-6.3.4.2(x64) Afs System 2 Fand LibOf Java so das nie! Nun findet sich da: Extras/Optionen/Erweitert OracleCorporation/13.0.1 Speicherort: C:\Programme-Files\Java\jdk-13.0.1 Es würde mich schon interessieren warum das sich so verhält. Was ist in LibOf V-6.3.3.2(x64) und V-6.3.4.2(x64) in dieser Hinsicht geändert worden, dass sich Java neuerdings nicht mehr direkt einbinden lässt? -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] JRE nicht auffindbar
Hallo Richard, vielen Dank für Deinen Link. Nach endlosen Versuchen mit Deinstallieren und reinstallieren von LobOf und Java, was alles nicht fruchtete, endlich mal ein Hinweis der das hielt was versprochen war! Gruss Marino Richard Kraut schrieb am 28.12.2019 um 21:28: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Samstag, den 28.12.2019, 11:32 +0100 schrieb Helmut Wolff: neuere Versionen, auch JDK, lassen sich bei mir nicht installieren. Ich kopiere aus dem herunter geladenen zip-Archiv den Ordner jdk-?? in einen gewünschten Überordner und registriere den Pfad in LO unter "Extras -> Optionen -> Erweitert". Übrigens: Andere Software, wie TV-Browser, hat einen eigenen java-Ordner. Dort hinein kopiere ich den Inhalt von jdk-??. Warum machst Du Dir es so kompliziert? Auf der Oracle Downloadseite für Java [1] kann man sich doch auch die Variante mit dem Installer (.exe) herunter laden. Ach ja. Ab der 11er-Version gibt es Java nur noch in einer 64-bit Ausführung. 1: " https://www.oracle.com/technetwork/java/javase/downloads/jdk13-downloads-5672538.html " - -- MfG Richi -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEERqPC1cUAShrzNBXW+NRy+KEKcZgFAl4HuvEACgkQ+NRy+KEK cZiRRQ//QEvT/+4f4IS4Kx1FRSEbvqh0WCLQ34D47MJeMlwPgbsjLZ7bbZ9PV9eQ G7+IiLiiHz6zlIZyoCdan9FlzBavpuFhoG4G7rpR4OyKwZcdLxoDw31k9pie3/GT uavXpRr53AOtPRYZUJ8d5/Wdu7uIa3CUFBVWJ7RfPih2DDBD220VSG0aIlaGBHXL y6uVBHk8JTnAc/kT+boARsEE1CtAEBxGLboV7mRu+xmxBcmCU02JGJCifHhqhJkP fvtuvcgZgv1dqUUah45ITBFZFqy/W99S4222bbFG/0jtTgxUqdNeFsxIOOpuLXWG w9vX2NBRrR8uw8LflRVzGG9yyxpKWlcSJEJuSZBRDZ66LaDmuJEK+x02zNKiFtLE +ERJWIG5Q2k8NSm9hZRERH+weHYLBDpEaEdTwu6SXXEgUCaM5zRv56fuITgZlH/u uJLKkflwGLtlfLiepY5+vN6bQitGWI5SOOyENa9polfzSwvxvdY2bhjDTzD8Rg5e XOvBTLF6lntqJrSO8eGvIj7r5madPSK8nsGKawLpH2QuvdmFcefO0Ccj04RaYm/1 Q38Lon7i3Yvat5OrpJLhHkQaUeFTryvDUqc0j5ZLGRtzC8MlnUfb9JnODf5D1Lnj M5o8eYq0woBGuN0pRwBE8UtKG4+6Wg1ntpcdAYmr6qSvqWZfP7I= =0+kF -END PGP SIGNATURE- -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: Solved: [de-users] Calc: Zeiten vereinfacht eingeben
Hallo Wolfgang Wolfgang Jäth schrieb am 28.12.2019 um 20:30: Am 28.12.2019 um 17:22 schrieb Marino Salvalaggio: Es tut mir leid, aber hier stimmt etwas nicht... Es werden bestimmt keine Kommastellen im Speicher verwendet! Das würde ja bedeuten, dass eine FLOAT bez. REAL in Anwendung wäre. Nein, DOUBLE. Das jedoch wäre mit der erheblichen Tatsache verbunden, dass je nach rechen-Operanden enorme Abweichungen der tatsächlichen Zeit resultieren würden. => https://de.wikipedia.org/wiki/Gleitkommazahl / Eigenschaften einer Gleitkommaarithmetik Ja, tut es; und ja, in der Tat, Rundungsfehler können im Extremfall bis in den Nanosekundenbereich druchschlagen. TIME wird in Millisekunden in INT hinterlegt, darum auch der beschränkte Umfang von ~±596 Std. Ich habe keine Ahnung, von welchem Programm du redest, von Calc jedenfalls nicht; da gibt es überhaupt keinen Variablentyp TIME o. ä. Und auch in Base aka der Makrosprache gibt es das nicht, höchstens die /Funktion/ TIME; den Variablentyp /DATE/. (das reicht nicht mal für einen Monat ~720h, aber für ms-genaue Wochenuhren und Funktion-Timer prädestiniert) Zeit und Datum DATE_AND_TIME werden daher im Speicher immer Binär in Anzahl Sekunden ab Fixpunkt hinterlegt. *Alle* Daten, sogar Texte, werden intern binär abgelegt. Und Calc selbst kennt überhaupt nur 3 Datentypen, nämlich String aka Text, Integer und Gleitkomma aka Double. Jep, aber nur bedingt richtig "Wahrheitswert" (BOOL) hast Du unterschlagen... und String ist in sich kein echter Datentyp sondern ein eindimensionales ARRAY zu 8Bit. Wenn das, was Du hier sagst richtig ist; das die Zeiten in Calc in Fliesskomma-Werten hinterlegt sind; dann werden bei gewissen Rechenoperationen unweigerlich Fehler auftrete. Nicht gerade das Gesuchte. In INT würde solches nie auftreten. Auf Leitsystemen mit Echtzeiteinträgen ist es Bedingung, dass die Zeitstempel kohärent sind! Gerade beim Abgleich von Letzt-wert, was in Leitebene als Bedingung für die Neuwert-Gültigkeit steht (DCP/IP Daten-Überholungen), eine absolute Bedingung. Somit kommt Calc als Tabelle für Datenhinterlegung für diesen Zweck nicht in Frage! Bei 32Bit DINT Was bitte ist ein DINT? Meinst du etwa LONG? Es ist mir sehr wohl bewusst, dass heute oft nur INT geschrieben wird, obwohl es eigentlich einen grösseren Bereich umfasst. Da kommt daher, dass auf einem Rechner die Grösse durch einen 16er-, 32er- oder 64er-BitProzessor festgelegt wird. So bezieht sich der Begriff INT heute zumeist auf die Maximal-Bit-zahl der Recheneinheit. Meine Aussagen beruhen aber auf den Standard von den grundsätzlichen ANY_INT Datentypen. SINT = ShortInteger 8Bit = 1 BYTE (in C CHAR ) -128...127 / 255 INT = Integer 16Bit= 2 BYTE -32768...32767 DINT = DoubleInteger32Bit= 4 BYTE LINT = LongInteger 64Bit= 8 BYTE Die Aufgliederung in BYTE ist darum zu berücksichtigen, weil die meisten seriellen Transportmittel; CAN, PROFIBUS, MODBUS, Ethernet; Byte-weise übertragen und die Speicher in Byte organisiert sind! Darum wird der Speicher in Byte-Grösse definiert und bei der Speicher-übertragung muss ja auch ein Pointer gesetzt werden, welcher auf die erste Byte-Adresse zeigt. Mit Vorstellung "U= für unsigned in Abwandlung ohne Negativwerte dafür doppelten Umfang (Höchstwertigels Bit wird nicht als Negativ sondern als Zahlenwert genutzt) Demselben Muster folgt auch ANY_REAL REAL = 32Bit LREAL= 64Bit ergibt das einen Umfang von ± ~68 Jahren vom gesetzten Bei einem DOUBLE ergibt sich ein Wertebereich von rund 4,93E+305 Jahren. Zum Vergleich, das Universum ist überhaupt erst ca. 1,37E+010 Jahre alt. Der Wertebereich reicht also durchaus noch ein paar Monate. Aber ja, mit Werten größer/kleiner ca. +/- 1,80E+308 kann Calc nicht mehr rechnen. Die Rechnung an sich ist trivial: 1Min = 60 Sek 1Std = 60 Min Bez. 3600Sek. Tag = 60*60*24 = 86400 Sekunden. Somit können Zeiten Addiert, Subtrahiert u. u. u. werden ohne dass spezielle Interpretationen benötigt werden. Im Prinzip ist deine Schlussfolgerung schon richtig. Aber sie gilt natürlich genauso, wenn 1 Sekunde als 1/86400 Tag aka 0,1157407407407410 Tage repräsentiert wird. 2 Sekunden ist in beiden Fällen das doppelte, 86400 Sekunden ist in beiden Fällen das 86400-fache, usw.; völlig problemlos, und ohne spezielle Interpretationen. Das würde sogar funktioneren, wenn du den Wert Pi für 1 Sekunde (oder 1 Tag, 1 Woche, 1 Jahr, 1 Millisekunde, oder sonst was, sogar mit sieben drittel Stunden, oder fünfundzwanzig siebenunddreißigstel Wochen, usw.) an nimmst. Da eine INT Zeit die in INT dividiert wird ohne Rest zurückgegeben wird (keine Rundung) kann diese direkt z.B. mit 60 geteilt werden und ich erhalte die Zeit in Minuten - u.s.w. Und was bitte machst du mit Millisekunden usw.? Solches macht der Zeitinterpreter. Die richtige Reihenfolge für ein Datum ist: Jahr.Monat.Tag.Stunde:Minute:Sekunde,Millisekunde Daraus ergibt sich eine
Re: Solved: [de-users] Calc: Zeiten vereinfacht eingeben
Hallo Gerhard, Gerhard Weydt schrieb am 27.12.2019 um 21:39: Hallo Marino, Am 27.12.2019 um 10:35 schrieb Marino Salvalaggio: ... Nach DIN EN 28601 galt im deutschen Sprachraum -MM-TT Diese wurde jedoch mit DIN 5008 (2001) zugunsten .MM.TT (wie in LibOf) wieder fallen gelassen! Das wurde nicht fallengelassen, es wurde nur die bisher in Deutschland verwendete Form TT.MM. (und nicht, wie du schreibst, die umgekehrte .MM.TT !!!) wieder offiziell zugelassen, weil sich keiner an die Standardform -MM-TT gehalten hat, was auch kein Wunder ist, weil dieser internationale Standard auch kaum irgendwo offensiv vertrieben und beworben wurde. Und LibO unterstützt selbstverständlich auch das internationale Format, gib mal in ein leeres Calc-Dokument 2019-12-27 ein, das ist dann anschließend als Datumsfeld erkannt worden, mit eben dieser Formatierung. LibO speichert Datum und Uhrzeit in einer Zahl, wobei die Vorkommastellen die Tage seit einem Stichtag zählen, den ich momentan nicht mehr weiß, das kann man ja ausprobieren, und die Nachkommstellen die Uhrzeit ergeben, 0,5 entspricht 12 Uhr. Es tut mir leid, aber hier stimmt etwas nicht... Es werden bestimmt keine Kommastellen im Speicher verwendet! Das würde ja bedeuten, dass eine FLOAT bez. REAL in Anwendung wäre. Das jedoch wäre mit der erheblichen Tatsache verbunden, dass je nach rechen-Operanden enorme Abweichungen der tatsächlichen Zeit resultieren würden. => https://de.wikipedia.org/wiki/Gleitkommazahl / Eigenschaften einer Gleitkommaarithmetik TIME wird in Millisekunden in INT hinterlegt, darum auch der beschränkte Umfang von ~±596 Std. (das reicht nicht mal für einen Monat ~720h, aber für ms-genaue Wochenuhren und Funktion-Timer prädestiniert) Zeit und Datum DATE_AND_TIME werden daher im Speicher immer Binär in Anzahl Sekunden ab Fixpunkt hinterlegt. Bei 32Bit DINT ergibt das einen Umfang von ± ~68 Jahren vom gesetzten Nullpunkt aus gerechnet; darum wird ja auch zwingend ein Fixpunkt benötigt. (Bei 32Bit-Rechnern musste daher für eine grössere Genauigkeit bez. grösseren Umfang auf 2 DINT geschiftet werden; eine Technik die unter 8Bit-Prozessoren früher zum täglichen Brot gehörten...) Die Rechnung an sich ist trivial: 1Min = 60 Sek 1Std = 60 Min Bez. 3600Sek. Tag = 60*60*24 = 86400 Sekunden. Somit können Zeiten Addiert, Subtrahiert u. u. u. werden ohne dass spezielle Interpretationen benötigt werden. Da eine INT Zeit die in INT dividiert wird ohne Rest zurückgegeben wird (keine Rundung) kann diese direkt z.B. mit 60 geteilt werden und ich erhalte die Zeit in Minuten - u.s.w. Solches macht der Zeitinterpreter. Dieser interpunktiert diese Resultate und gibt die Werte nach Addition mit dem Fixpunkt formatiert aus: DD.MM. hh:mm:ss aus. In Jahresbereich muss jedoch ein Kalender mit integriert sein, damit die Schalttage mit einfliessen sonst kommt es zu Interpretationsabweich-ungen! Bei 64Bit LINT ist die Beschränkung an sich kein Thema ist doch der Bereich bei ±1.45E11 Jahre in Sekunden; daher kann hier die Formatierung auch bis Millisekunde genau ausgegeben werden. Was man an der Oberfläche sieht, ist immer umgerechnet und formatiert. Keine der vielen möglichen Formen ist besser oder schlechter als die andere, LibO ist da neutral. Gruß Gerhard Gruss Marino -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: Solved: [de-users] Calc: Zeiten vereinfacht eingeben
Hi Gerhard, jep das hast Du richtig erkannt, habe mich da vertan... Gerhard Weydt schrieb am 27.12.2019 um 21:39: Hallo Marino, Am 27.12.2019 um 10:35 schrieb Marino Salvalaggio: ... Nach DIN EN 28601 galt im deutschen Sprachraum -MM-TT Diese wurde jedoch mit DIN 5008 (2001) zugunsten .MM.TT (wie in LibOf) wieder fallen gelassen! Das wurde nicht fallengelassen, es wurde nur die bisher in Deutschland verwendete Form TT.MM. (und nicht, wie du schreibst, die umgekehrte .MM.TT !!! Die Reihenfolge ist im deutschsprachigen Raum tatsächlich umgekehrt; was jedoch keinen Einfluss auf die abgespeicherten Daten hat, da diese nicht Sprach-gebunden hinterlegt sind. Diese Werte werden nur jeweils anders interpretiert ausgegeben. Es gilt jedoch zu beachten, dass wesentlicher Unterschiede zwischen: A. TIME und DATE_AND_TIME (DIN) B. Time_of_Day und Date_and_Time_of Day (ISO) bestehen. Die binäre Hinterlegung folgt dabei nicht der gleichen Gesetzen. In diesem Zusammenhang ist mir aufgefallen, dass in LibOf eine unschöne Ungereimtheit existiert. Da bei der DtTm Eingabe "Zellen formatieren" Datum und Uhrzeit die Platzhalter für: 1. Datum TT.MM. 2. Uhrzeit HH:MM:DD verwendet werden, erfolgt das unangenehme Ersetzen von Uhrzeit in Datum, wenn "MM" als Format_Code eingefügt wird. Wird ":MM" oder "MM:" geschrieben, dann bleibt die Minute von Time, jedoch erscheint nun in der Tabelle der Wert mit vor- bez, nach-gestelltem Doppelpunkt; gerade das, was es unmöglich macht hier eine Glanzzahl einzusetzen! In gewissen Programmieroberflächen welche Format-restriktiv sind, sind die Datums-Platzhalter in Grossbuchstaben-, die Zeit-Platzhalter in Kleinbuchstaben gehalten (e); DD.MM. / hh:mm:ss,ms damit solche Vertauschungen gar nicht erst auftreten können! ) wieder offiziell zugelassen, weil sich keiner an die Standardform -MM-TT gehalten hat, was auch kein Wunder ist, weil dieser internationale Standard auch kaum irgendwo offensiv vertrieben und beworben wurde. Und LibO unterstützt selbstverständlich auch das internationale Format, gib mal in ein leeres Calc-Dokument 2019-12-27 ein, das ist dann anschließend als Datumsfeld erkannt worden, mit eben dieser Formatierung. LibO speichert Datum und Uhrzeit in einer Zahl, wobei die Vorkommastellen die Tage seit einem Stichtag zählen, den ich momentan nicht mehr weiß, das kann man ja ausprobieren, und die Nachkommstellen die Uhrzeit ergeben, 0,5 entspricht 12 Uhr. Was man an der Oberfläche sieht, ist immer umgerechnet und formatiert. Keine der vielen möglichen Formen ist besser oder schlechter als die andere, LibO ist da neutral. Gruß Gerhard Gruss Marino -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] JRE nicht auffindbar
Hi Harald, Ich sende Dir das direkt, da meine Screenshot nicht im Forum ausgegeben werden... Warum LobOf das JRE nicht finden kann weiss der Geier... habe wirklich alles Mögliche versucht; Resultat keines! Geht einfach nicht, hoffe jemand weiss da Rat... Gruss Marino lo.harald.ber...@t-online.de schrieb am 27.12.2019 um 06:48: > Hi Marino, > > Hast du auch wirklich die 64-Bit Java Version installiert? > > Hier findest du eine Anleitung: > > https://wiki.documentfoundation.org/DE/Das_richtige_JRE_installieren > > ich hoffe es hilft dir weiter. > > Freundliche Grüße > > Harald > > Am 27.12.2019 um 06:26 schrieb Marino Salvalaggio: >> Hi, >> >> wie Ihr Euch wahrscheinlich erinnert, habe ich die Version auf meinen >> 2 Systemen auf die Version 6.3.3.2 (x64) angehoben. >> Damals habe ich den merkwürdigen Absturz bei den Erweiterungen - >> anschliessend bis jetzt alles Ready. >> >> Nun musste ich mal Java auf System 2 auf V 1.8.0_231 nachziehen. >> (Ist auf System 1 so Aktiv und funktioniert!) >> >> Was aber geschieht nun... >> >> Meldung von LbOf => JRE ist erforderlich >> - LibreOffice benötigt eine 64-Bit Java Runtime Environment (JRE), um >> - diese Aufgabe auszuführen. Bitte installieren Sie eine JRE und starten >> - Sie LibreOffice neu. >> Klar doch => Optionen/Erweitert => Eine Java-Laufzeit verwenden / Ja! >> >> Resultat: das Ding findet diese Java-Version einfach nicht! >> >> Java deinstalliert => neu installiert => kein Java auffindbar ??? >> >> Was muss ich tun, damit LobOf das nun auf dem System findet? >> >> Marino >> > -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: Solved: [de-users] Calc: Zeiten vereinfacht eingeben
Hallo Boris, eigentlich ist sowohl die Zeit wie auch das Datum eine spezielle Speicherart welche zumeist als uInt litleendian im System hinterlegt wird. Als "TIME" gilt unter 32Bit: Auflösung in Millisekunden T# -596h31m23s648ms...59h31m23s647ms Dieses Format scheint auch in LibOf genutzt zu werden; ob das jedoch wirklich ms genau ist weiss nehme ich an... aber das müssten dann schon die Programmierer beantworten; jedenfalls ist in Calc eine solche mit Formatierung MM:MM:SS,ms verfügbar... Als DATE_AND_TIME unter 32Bit gilt: Auflösung Sekunden Dabei gibt es eine Fixpunkt von welchem aus der Nullpunkt definiert ist. Fixpunkt 1.1.1970 00:00:00 DT# 2106-02-07-06:28:15 -(ps. hier ist zu beachten, dass diverse Fixpunkte in Anwendung sind. - über viele Jahre war das 1.1.1900.00:00:00 - unter 64Bit ist das jedoch kein Thema mehr, da ein Überlauf bei - unserer Lebensdauer nicht mehr zu befürchten ist) Nach DIN EN 28601 galt im deutschen Sprachraum -MM-TT Diese wurde jedoch mit DIN 5008 (2001) zugunsten .MM.TT (wie in LibOf) wieder fallen gelassen! Diese Numerische Darstellung ermöglicht es, die Rechenoperatoren direkt auf Zeitformate anzuwenden, jedoch müssen diese via Interpretation ausgegeben werden. Das ist der Grund, warum diese Zeitformate nur via Umrechnung zu deuten sind und nicht einfach so in einer Tabelle eingetragen werden können! Um nun in Calk rein numerische Werte eingeben zu können gibt es eine ganz einfache Lösung: Dazu nehmen wir mal zwei Spalten mit vier Zeilen 1. Spalte A für die rein numerischen Eingaben: Zeile 1 Stunden => Dezimal Standard Zeile 2 Minuten => Dezimal Standard Zeile 3 Sekunden => Dezimal Standard 2. Spalte B Ausgabe im Zeitformat Zeile 1 =ZEIT(A1;0;0) => Format Zeit Zeile 2 =ZEIT(0;A2;0) => Format Zeit Zeile 3 =ZEIT(0;0;A3) => Format Zeit 3. Spalte TIME-Ausgabe Zeile 4 =B1+B2+B3 => Format Zeit Diese Funktion kann auf alle Datentypen Zeit oder Datum angewandt werden und Calc gibt so immer die interpretierte Zeit/Datum Form aus! schönen Tag und gutes Neues Jahr Marino Boris Kirkorowicz schrieb am 26.12.2019 um 23:05: > Hallo, > vielen Dank für die vielen Anregungen. Für mich habe ich das jetzt so > gelöst: > > Spalte C: von -Zeit, Format: #":"##;[ROT]-#":"## > Gültigkeit: Jeder Wert > > Spalte D: bis -Zeit, Format: #":"##;[ROT]-#":"## > Gültigkeit: Ganze Zahl, Gültiger Bereich: 0 ... 2400 > > Berechnung der Dauer (hier in Zeile 3): >> =WENN(ODER(C3="";D3="");"";(GANZZAHL(D3/100)+(D3-(GANZZAHL(D3/100)*100))/60)-(GANZZAHL(C3/100)+(C3-(GANZZAHL(C3/100)*100))/60)) > Format: #.##0,00;[ROT]-#.##0,00 > > Das ist zwar kein richtiges Zeitformat, erfüllt fürs erste meine > Anforderung: nach Tippen von > 1315 > erscheint > 13:15 > und die Dauer wird auch richtig berechnet und kann weiterverarbeitet > werden, wenn auch nicht als Zeit, sondern als Dezimalzahl. > ¦ -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
[de-users] JRE nicht auffindbar
Hi, wie Ihr Euch wahrscheinlich erinnert, habe ich die Version auf meinen 2 Systemen auf die Version 6.3.3.2 (x64) angehoben. Damals habe ich den merkwürdigen Absturz bei den Erweiterungen - anschliessend bis jetzt alles Ready. Nun musste ich mal Java auf System 2 auf V 1.8.0_231 nachziehen. (Ist auf System 1 so Aktiv und funktioniert!) Was aber geschieht nun... Meldung von LbOf => JRE ist erforderlich - LibreOffice benötigt eine 64-Bit Java Runtime Environment (JRE), um - diese Aufgabe auszuführen. Bitte installieren Sie eine JRE und starten - Sie LibreOffice neu. Klar doch => Optionen/Erweitert => Eine Java-Laufzeit verwenden / Ja! Resultat: das Ding findet diese Java-Version einfach nicht! Java deinstalliert => neu installiert => kein Java auffindbar ??? Was muss ich tun, damit LobOf das nun auf dem System findet? Marino -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] Extension Manager
Hallo Harald, Harald Köster schrieb am 30.11.2019 um 20:17: > Hallo Marino, > > Am 29.11.2019 um 07:24 schrieb Marino Salvalaggio: >> Hallo Harald, >> >> Zuerst einmal möchte ich hier grundsätzlich Klarheit schaffen! >> >> 1. Bei mir sind zwei Rechner #1 mit identischer Windows-Version in >> Betrieb; beides HP Z230 64Bit >> CPU=Intel/Xenon E3-1225v3 3.2 GHz/RAM 12.00GB Systeme. >> 2. Nur auf einem System ist die fehlende (=> LibreoOffice Draw) >> Extension nachinstalliert und dieser Rechner war von diesem Update nicht >> betroffen! >> 3. Nur jenes System welche von mir gestern nachträglich nachgezogen >> wurde und keine zusätzliche Extension hat war betroffen und hat das >> erwähnte Einfrieren produziert! >> >> Harald Köster schrieb am 28.11.2019 um 22:14: >>> Hallo Marino, >>> >>> Am 28.11.2019 um 12:56 schrieb Marino Salvalaggio: >>>> Hi, >>>> >>>> habe heute ein weiteres Problem mit der neuen Version 6.3. >>>> >>>> habe ein PrnScrn angehängt, nehme jedoch an, dass das im Forum nicht >>>> portiert wird. >>>> >>>> Darum hier der Beschrieb: >>>> >>>> Beim öffnen einer Datei => neue Extension verfügbar >>>> Beim Klick darauf erfolgt: >>>> Einblendung Extension Update => suche läuft... >>>> dann plötzlich => Einblendung Fehler => >>>> http://dl.dropbox.com/u/14712909/macro/w2e/writer2epub.update.xml => >>>> existiert nicht >>>> Klick auf OK >>>> Einblendung Fehler => Fehler beim lesen der Daten aus dem Internet. >>>> Systemfehlermeldung:. >>>> >>>> Nach einer vollständigen Blockierung des Systems >>>> / musste LibO mittels Taskmanager abschiessen! >>>> >>>> Neustart von LibO erneute Extension Meldung gleicher Ablauf - nun aber >>>> kein Hänger nach wiederholtem Klick auf OK plötzlich Extension >>>> eingelesen und Inst-all lief einwandfrei ab... >>>> >>>> Habe nicht durchschaut woran das Ganze hängt, jedoch sind die Dateien; >>>> warum auch immer; eingefügt worden... >>>> >>>> Soweit so gut, nur ist das sicherlich nicht das richtige Prozedere. >>>> >>>> Wäre gut, dass das Andere mal nachvollziehen, damit die entsprechenden >>>> Modifikationen erfolgen können. >>> >>> ich hatte vor Kurzem ein ähnliches Problem mit 'nem Crash und Freeze in >>> Zusammenhang mit dem Update von Extensions: >>> https://bugs.documentfoundation.org/show_bug.cgi?id=127645 >>> >>> Mir scheint aber, dass es sich dabei nicht um gleiche Problem handelt. >>> Um Dein Problem reproduzieren zu können, bräuchte man weitere Infos: >>> (*) Dein Betriebssyste >> >> Windows 10Pro, Ver. 1909, Build 18363.476 >> >>> (*) Die genaue LibreOffice-Version >> Version:6.3.3.2(x64) Build-ID: a64200df03143b798afd1ec74a12ab50359878ed >> >>> (*) Die veraltete Extension mit welcher Version> (*) Handelt es sich dabei >>> um die Extension writer2epub. Mir scheint, >>> dass diese Extension nicht mehr gepflegt wird: >>> https://extensions.libreoffice.org/extensions/writer2epub >> >> http://dl.dropbox.com/u/14712909/macro/w2e/writer2epub.update.xml >> >> dabei erfolgt die Meldung Drpbox - 404: Error (404) >> We can't find the page you're looking for. >> Here are a few links that may be helpful: >> >> Home >> Help center >> Sign in >> Get a free account >> Dropbox Plus >> Dropbox Business >> >> >> Ehrlich keine Ahnung was und warum das nur aus #2 nachgezogen werden sollte. >> Dürft jedoch älteren Datums gewesen sein, da ich die LibO Version schon >> sein der 1. Installation von MS-Win aufsetzte ist und seit damals schon >> mehrmals nachgezogen worden; seit welcher Version weiss ich beim besten >> Willen nicht mehr zu sagen. >> Die Update welche von LibO angemeldet wurden habe ich immer erst auf dem >> System #1 ausgeführt. Erst wenn anschliessend keine Probleme auftreten >> installiere ich diese auch auf dem System #2; sonst warte ich in der >> Regel ab, bis das System #1 mit allfällig notwendigen Korrekturen >> einwandfrei läuft. >> >> Das war eben gestern, da das System #1 ja problemlos läuft. Das >> Extension-Update wurde auf #1 aber nicht angeboten und beim Nachziehen >> des Systems #2 ist das Beschriebene dort aufgetreten... > > mit Deiner Beschreibung wird es kaum mögli
Re: [de-users] Extension Manager
Hallo Harald, Zuerst einmal möchte ich hier grundsätzlich Klarheit schaffen! 1. Bei mir sind zwei Rechner #1 mit identischer Windows-Version in Betrieb; beides HP Z230 64Bit CPU=Intel/Xenon E3-1225v3 3.2 GHz/RAM 12.00GB Systeme. 2. Nur auf einem System ist die fehlende (=> LibreoOffice Draw) Extension nachinstalliert und dieser Rechner war von diesem Update nicht betroffen! 3. Nur jenes System welche von mir gestern nachträglich nachgezogen wurde und keine zusätzliche Extension hat war betroffen und hat das erwähnte Einfrieren produziert! Harald Köster schrieb am 28.11.2019 um 22:14: > Hallo Marino, > > Am 28.11.2019 um 12:56 schrieb Marino Salvalaggio: >> Hi, >> >> habe heute ein weiteres Problem mit der neuen Version 6.3. >> >> habe ein PrnScrn angehängt, nehme jedoch an, dass das im Forum nicht >> portiert wird. >> >> Darum hier der Beschrieb: >> >> Beim öffnen einer Datei => neue Extension verfügbar >> Beim Klick darauf erfolgt: >> Einblendung Extension Update => suche läuft... >> dann plötzlich => Einblendung Fehler => >> http://dl.dropbox.com/u/14712909/macro/w2e/writer2epub.update.xml => >> existiert nicht >> Klick auf OK >> Einblendung Fehler => Fehler beim lesen der Daten aus dem Internet. >> Systemfehlermeldung:. >> >> Nach einer vollständigen Blockierung des Systems >> / musste LibO mittels Taskmanager abschiessen! >> >> Neustart von LibO erneute Extension Meldung gleicher Ablauf - nun aber >> kein Hänger nach wiederholtem Klick auf OK plötzlich Extension >> eingelesen und Inst-all lief einwandfrei ab... >> >> Habe nicht durchschaut woran das Ganze hängt, jedoch sind die Dateien; >> warum auch immer; eingefügt worden... >> >> Soweit so gut, nur ist das sicherlich nicht das richtige Prozedere. >> >> Wäre gut, dass das Andere mal nachvollziehen, damit die entsprechenden >> Modifikationen erfolgen können. > > ich hatte vor Kurzem ein ähnliches Problem mit 'nem Crash und Freeze in > Zusammenhang mit dem Update von Extensions: > https://bugs.documentfoundation.org/show_bug.cgi?id=127645 > > Mir scheint aber, dass es sich dabei nicht um gleiche Problem handelt. > Um Dein Problem reproduzieren zu können, bräuchte man weitere Infos: > (*) Dein Betriebssyste Windows 10Pro, Ver. 1909, Build 18363.476 > (*) Die genaue LibreOffice-Version Version:6.3.3.2(x64) Build-ID: a64200df03143b798afd1ec74a12ab50359878ed > (*) Die veraltete Extension mit welcher Version> (*) Handelt es sich dabei um > die Extension writer2epub. Mir scheint, > dass diese Extension nicht mehr gepflegt wird: > https://extensions.libreoffice.org/extensions/writer2epub http://dl.dropbox.com/u/14712909/macro/w2e/writer2epub.update.xml dabei erfolgt die Meldung Drpbox - 404: Error (404) We can't find the page you're looking for. Here are a few links that may be helpful: Home Help center Sign in Get a free account Dropbox Plus Dropbox Business Ehrlich keine Ahnung was und warum das nur aus #2 nachgezogen werden sollte. Dürft jedoch älteren Datums gewesen sein, da ich die LibO Version schon sein der 1. Installation von MS-Win aufsetzte ist und seit damals schon mehrmals nachgezogen worden; seit welcher Version weiss ich beim besten Willen nicht mehr zu sagen. Die Update welche von LibO angemeldet wurden habe ich immer erst auf dem System #1 ausgeführt. Erst wenn anschliessend keine Probleme auftreten installiere ich diese auch auf dem System #2; sonst warte ich in der Regel ab, bis das System #1 mit allfällig notwendigen Korrekturen einwandfrei läuft. Das war eben gestern, da das System #1 ja problemlos läuft. Das Extension-Update wurde auf #1 aber nicht angeboten und beim Nachziehen des Systems #2 ist das Beschriebene dort aufgetreten... Gruss Marino > > Grüße > Harald > -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
[de-users] Extension Manager
Hi, habe heute ein weiteres Problem mit der neuen Version 6.3. habe ein PrnScrn angehängt, nehme jedoch an, dass das im Forum nicht portiert wird. Darum hier der Beschrieb: Beim öffnen einer Datei => neue Extension verfügbar Beim Klick darauf erfolgt: Einblendung Extension Update => suche läuft... dann plötzlich => Einblendung Fehler => http://dl.dropbox.com/u/14712909/macro/w2e/writer2epub.update.xml => existiert nicht Klick auf OK Einblendung Fehler => Fehler beim lesen der Daten aus dem Internet. Systemfehlermeldung:. Nach einer vollständigen Blockierung des Systems / musste LibO mittels Taskmanager abschiessen! Neustart von LibO erneute Extension Meldung gleicher Ablauf - nun aber kein Hänger nach wiederholtem Klick auf OK plötzlich Extension eingelesen und Inst-all lief einwandfrei ab... Habe nicht durchschaut woran das Ganze hängt, jedoch sind die Dateien; warum auch immer; eingefügt worden... Soweit so gut, nur ist das sicherlich nicht das richtige Prozedere. Wäre gut, dass das Andere mal nachvollziehen, damit die entsprechenden Modifikationen erfolgen können. Gruss Marino -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
Re: [de-users] LibreOffice Draw
Hi, vielen Dank für Eure Hilfe! Zum Einen möcht ich mich für meine verpätete Rückmeldung entschuldigen - leider wurden alle Rückmeldungen von Euch im meinem Account im Spam blockiert, mia culpa. Zum Zweiten möchte ich hier anmerken, dass ich schon erstaunt bin, dass extensions durch einen Update einfach so verschwinden. War bei den vorherigen Versionen nicht so! Ist auch der Grund, dass ich die schon sehr lange benutze und daher gar nicht mehr wusste woher ich die Importiert hatte... Ob das jetzige Verhalten so gewollt ist kann ich jedoch nicht nachvollziehen. Schönen Gruss Marino Alois Klotz schrieb am 26.11.2019 um 17:08: > Hallo, > die Elektroniksymbole sind bei mir auch nicht in der gallery. > Es gibt sie aber als Extension OxygenOffice Extras - der Download ist > aber extrem langsam. > > Ich habe sie in meiner Dropbox gespeichert: > https://www.dropbox.com/s/jwfyvnjoyap45fy/ooop-accessories-2.8.0.0.oxt?dl=0 > > Hier eine Vorschau auf die Symbole: > https://www.dropbox.com/s/gwfpwksa0ghslgl/electronic_symbols.png?dl=0 > > MfG Alois > > > > Marino Salvalaggio schrieb am 26.11.2019 um 13:21: >> Hallo, >> >> leider musste mit erstaunen feststellen, dass nach dem Update auf die >> letzte Version 6.3.2.2 (x64) plötzlich die Elektroniksymbole nicht mehr >> auffindbar sind. >> Dummerweise gerade, als ich im Begriff war, an einer angefangene Arbeit >> weiter zu arbeiten . Wo sind die bloss hin gekommen? >> >> Weiss einer wie ich wieder zu meinen Transistoren PNP & NPN, >> Kondensatoren und weitere E-Symbole der vormaligen Bibliothek komme? >> >> Wäre sehr dankbar um einen guten Rat... >> >> BiBa Marino >> > > -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
[de-users] LibreOffice Draw
Hallo, leider musste mit erstaunen feststellen, dass nach dem Update auf die letzte Version 6.3.2.2 (x64) plötzlich die Elektroniksymbole nicht mehr auffindbar sind. Dummerweise gerade, als ich im Begriff war, an einer angefangene Arbeit weiter zu arbeiten . Wo sind die bloss hin gekommen? Weiss einer wie ich wieder zu meinen Transistoren PNP & NPN, Kondensatoren und weitere E-Symbole der vormaligen Bibliothek komme? Wäre sehr dankbar um einen guten Rat... BiBa Marino -- Liste abmelden mit E-Mail an: users+unsubscr...@de.libreoffice.org Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Datenschutzerklärung: https://www.documentfoundation.org/privacy
