W
Webermeister
Neues Mitglied
- 0
Zu #20:
Das Kernergebnis der ‚KOGNIK‘ lautet: All ihre Dateien haben als Netzwerk von Natur aus die Gestalt eines ‚Abstraktionskegels‘! Die Kegelartigkeit mit all ihren ‚Durchzoombarkeits‘-Ebenen gilt es dort den Klienten hautnah vorzuführen. Das (ungewohnte) Konzept nicht etwa vor ihnen zu verbergen. Zumindest aus der *.zip-Datei heraus funktioniert das problemlos. Ohne - qualitativ - solche Abstriche!
Zu #19:
Wenn das nur so einfach wäre!
Die zusätzliche Abspeicherung der Text-Dateien in einer *.htm-Version und die Abänderung aller Hyperlinks zu diesen „Tochter“-Dateien im \Datei-Index würde den Klienten zwar Einblick sogar schon in dessen „Enkel“-Dateien verschaffen. („Öffnen möglich“!). Doch wird die Offenlegung genealogisch leider nicht auf die „Urenkel“-Ebene usw. weitervererbt. Deren Tausende an internen Links bleiben weiterhin die *.doc-, *.pdf- oder *.jpg-Links, als die sie angelegt wurden. Jeder von diesen zeigt dann das Problem: „Öffnen nicht möglich.“.
(Wie versprochen
Eine Stufe tiefer geschürft
Aus meinem Riesennetzwerk mit über 10.000 Hyperlinks heraus habe ich irgendeine Text-Datei (doc / pdf / htm / …) per ‚Website-Ansteuerung‘ ausgewählt: https://kognik.de/ORIGINAL/… und diese als „Mutter“-Datei zu mir her auf den PC oder das Android-Smartphone geladen. (Dort zunächst in der *.doc-Fassung ihres sachlichen Inhalts - z. B. ONLINE aus: https://kognik.de/ORIGINAL/buchtop/datei-index.doc als lokale OFFLINE-Datei erzeugt. Nach dem (problemlosen) Öffnen dieser Datei lassen sich all die dort in die Aufzählung eingebauten Links zu anderen *.doc-Datei öffnen und jeweils OFFLINE herunterladen. Jedoch werden die in diesen „Töchtern“ weiter zu „ENKEL“-Dateien“ führenden Hyperlinks angezeigt als:
Und versagen – nach der Warnung: „Dieser Speicherort ist möglicherweise nicht sicher“ –
als falsch-formulierte OFFLINE-Pfade zwangsläufig den Dienst.
Wegen dieses Dauer-Ärgernisses habe ich zu manchen der Inhalte von KOGNIK.de extra eine Zweit-Fassung im *.htm-Format angefertigt und diese parallel zur *.doc-Version auf diese Website hochgeladen.
Innerhalb einer solchen, jetzt in der Rolle der „Mutter“ heruntergeladenen *.htm-Datei“ dagegen (hier: /buchtop/datei_index.htm) starten die inhaltlich selben „Töchter“ ihre eigenen Hyperlink-Pfade dieses Mal mit:
Und öffnen und speichern solche ONLINE-Aufrufe brav!
Doch „Enkel“-Hyperlinks in solchen OFFLINE-„Töchtern“ (hier innerhalb von: \a_meth/a-kegel.doc oder dergleichen angelegt) sperren ebenso wie oben. Das Problem ist nur um eine genealogische Ebene nach unten verlagert.
Außer ihr eigener Pfad endet auf *.htm, und verlangt damit einen ONLINE-Zugriff.
ERKENNTNIS:
Wird in einer „Mutter“-Datei irgendein (egal welcher) interner Hyperlink angeklickt (soll dabei beim Klienten eine „Tochter“-Datei neu erzeugen), so ist dafür (meistens) ein ganz anderes Programm zuständig als dasjenige für die Übertragung der „Mutter“-Datei selbst (dort immerzu: https://...)
Welches Programm / Welcher Bowser dann in Aktion tritt, hängt davon ab, wie Datei-Endung des fraglichen internen Hyperlinks lautet:
Die Ursachenfindung ist somit eingegrenzt auf:
Bei der Suche nach der Lösung gilt es im Zuge des Herbringens der jeweils fraglichen Datei die fehlgeleitete ABÄNDERUNG ihrer internen PFADANFÄNGE von der auf dem Server vorliegenden ONLINE-Version hin zur lokal funktionsfähig benötigten OFFLINE-Version zu verhindern. Dort „liegt der Hund begraben“!
Doch wie dieses Verhindern (bei WORD usw.) technisch zuzugehen hat, habe ich bisher nicht herausgebracht.
Auf jeden Fall stammt der Eintrag des Ziel-Rechners (…/Users/XWM/… ) von meinem PC mit genau diesem Namen her. Irgendwoher wird er im Zuge des Herunterladens aufgegriffen. Und dann lokal per: file:///C:/Users/XWM/… zur Erzeugung ärgerlicher Links verwendet.
Statt: https://kognik.de/ONLINE/... , so wie es als Pfadanfang von der Mutterdatei her auf dem Server längst bekannt ist, bei deren Los-Senden aber nicht in die „Töchter“-, „Enkel“- und „Urenkel“-Dateien hinein „genealogisch vererbt“ wird!
{Weitere Verhaltens-Tests bei: WINDOWS 10 + 11 / LINUX / APPLE- und anderen Betriebssystemen!! – Jeweils hin zu Tischgeräten, Laptops und Phones.}
Früher war mir mal aufgefallen, dass WORD-Dateien, die „nach einem Absturz wiederhergestellt waren“, bei mir nicht etwa im selben lokalen Verzeichnis landeten, in dem deren Original abgespeichert ist. Die trugen ebenfalls den ominösen Pfad-Anfang: file:///C:/Users/XWM/... . Auch deren interne Hyperlinkpfade waren: durch die Bank „zerschossen“.
Was also müsste man für WORD / Acrobat / LibreOffice / Android / PowerPoint + … in ihren „Speichern-Dialog“ (oder sonst irgendwo) „WO? und WIE?“ eintragen, damit diese Abänderung in beiden Fällen unterbleibt?
Siehe etwa unter: „WORD --- Optionen --- Speichern --- Dokumente Speichern“
die dortigen Vorgaben für Pfad-Anfänge gemäß:
„Lokaler Standardspeicherort für Datei“
oder aber gemäß:
– „Standardspeicherort für persönliche Vorlagen“ ??
{hierfür einen Pfad vorgeben, der sich den Pfadanfang bei der „Mutter“-Datei abholt!}
N. B.: Beide Mal geht es um die „OFFLINE-Neuanlage einer Datei“!
Unter: Formate von Dateipfaden unter Windows-Systemen - .NET
findet sich dazu zwar vieles an Optionen. Mir jedoch sind diese noch unverständlich!
Sodass auch ich selbst „Eine brauchbare Lösung des Grundproblems“ noch nicht kenne.
Zurück zum Original-Problem #1
(„Wenn ich nun die gesamte Word Datei auf mein Handy ziehe und dort dann auf die PDF klicke, tut sich rein gar nichts.“)
Auf meinem / jedem PC ist sowohl die *.doc-Mutter als auch die *.pdf-Tochter dabei auf ein und demselben Gerät gespeichert. Auf dem PC zunächst. Und dort funktioniert der Abruf des Links zur *.pdf-Tochter problemlos.
Nach dem Umziehen aufs Handy sind wiederum die Word-Datei als auch die PDF-Datei auf ein und demselben Gerät gespeichert. Diesmal auf einem Android-Smartphone.
Und da funktioniert derselbe (unveränderte) Link extra überraschenderweise nicht! Obwohl dort keinerlei§?§ Herunterladen von außen her und kein Neuanlegen der *.doc-Datei involviert ist. (Anders§?§ also als in meinem „Website-Fall“.)
Auch da spuckt intern bei der Übergabe des Kommandos von *.doc an *.pdf ein verfälschender Pfad-Anfang dazwischen.
Das Kernergebnis der ‚KOGNIK‘ lautet: All ihre Dateien haben als Netzwerk von Natur aus die Gestalt eines ‚Abstraktionskegels‘! Die Kegelartigkeit mit all ihren ‚Durchzoombarkeits‘-Ebenen gilt es dort den Klienten hautnah vorzuführen. Das (ungewohnte) Konzept nicht etwa vor ihnen zu verbergen. Zumindest aus der *.zip-Datei heraus funktioniert das problemlos. Ohne - qualitativ - solche Abstriche!
Zu #19:
Wenn das nur so einfach wäre!
Die zusätzliche Abspeicherung der Text-Dateien in einer *.htm-Version und die Abänderung aller Hyperlinks zu diesen „Tochter“-Dateien im \Datei-Index würde den Klienten zwar Einblick sogar schon in dessen „Enkel“-Dateien verschaffen. („Öffnen möglich“!). Doch wird die Offenlegung genealogisch leider nicht auf die „Urenkel“-Ebene usw. weitervererbt. Deren Tausende an internen Links bleiben weiterhin die *.doc-, *.pdf- oder *.jpg-Links, als die sie angelegt wurden. Jeder von diesen zeigt dann das Problem: „Öffnen nicht möglich.“.
********************************************************
(Wie versprochen
Eine Stufe tiefer geschürftAus meinem Riesennetzwerk mit über 10.000 Hyperlinks heraus habe ich irgendeine Text-Datei (doc / pdf / htm / …) per ‚Website-Ansteuerung‘ ausgewählt: https://kognik.de/ORIGINAL/… und diese als „Mutter“-Datei zu mir her auf den PC oder das Android-Smartphone geladen. (Dort zunächst in der *.doc-Fassung ihres sachlichen Inhalts - z. B. ONLINE aus: https://kognik.de/ORIGINAL/buchtop/datei-index.doc als lokale OFFLINE-Datei erzeugt. Nach dem (problemlosen) Öffnen dieser Datei lassen sich all die dort in die Aufzählung eingebauten Links zu anderen *.doc-Datei öffnen und jeweils OFFLINE herunterladen. Jedoch werden die in diesen „Töchtern“ weiter zu „ENKEL“-Dateien“ führenden Hyperlinks angezeigt als:
file:///c:\users\xwm\ mit z. B.: \a_meth\a-kegel.doc – und Ähnlichem.
Und versagen – nach der Warnung: „Dieser Speicherort ist möglicherweise nicht sicher“ –
als falsch-formulierte OFFLINE-Pfade zwangsläufig den Dienst.
Wegen dieses Dauer-Ärgernisses habe ich zu manchen der Inhalte von KOGNIK.de extra eine Zweit-Fassung im *.htm-Format angefertigt und diese parallel zur *.doc-Version auf diese Website hochgeladen.
Innerhalb einer solchen, jetzt in der Rolle der „Mutter“ heruntergeladenen *.htm-Datei“ dagegen (hier: /buchtop/datei_index.htm) starten die inhaltlich selben „Töchter“ ihre eigenen Hyperlink-Pfade dieses Mal mit:
kognik.de/ONLINE/ hier z. B.: \a_meth\a-kegel.doc .
Und öffnen und speichern solche ONLINE-Aufrufe brav!
Doch „Enkel“-Hyperlinks in solchen OFFLINE-„Töchtern“ (hier innerhalb von: \a_meth/a-kegel.doc oder dergleichen angelegt) sperren ebenso wie oben. Das Problem ist nur um eine genealogische Ebene nach unten verlagert.
Außer ihr eigener Pfad endet auf *.htm, und verlangt damit einen ONLINE-Zugriff.
ERKENNTNIS:
Wird in einer „Mutter“-Datei irgendein (egal welcher) interner Hyperlink angeklickt (soll dabei beim Klienten eine „Tochter“-Datei neu erzeugen), so ist dafür (meistens) ein ganz anderes Programm zuständig als dasjenige für die Übertragung der „Mutter“-Datei selbst (dort immerzu: https://...)
Welches Programm / Welcher Bowser dann in Aktion tritt, hängt davon ab, wie Datei-Endung des fraglichen internen Hyperlinks lautet:
- WORD / LibreOffice / … --- für *.doc oder *.docx- Endungen
- Adobe Acrobat oder … --- für *.pdf-Links
- Foto-Anzeige oder … --- für *.jpg-Links und dergl.
- Internetbrowser wie Microsoft Edge und Firefox oder aber Android und …
--- Jedoch nur dort funktionierend, wo ich zuvor bei der Hyperlink-Auszeichnung speziell auf die *.htm-Fassung des gesuchten Inhalts verwiesen habe.
Die Ursachenfindung ist somit eingegrenzt auf:
Bei der Suche nach der Lösung gilt es im Zuge des Herbringens der jeweils fraglichen Datei die fehlgeleitete ABÄNDERUNG ihrer internen PFADANFÄNGE von der auf dem Server vorliegenden ONLINE-Version hin zur lokal funktionsfähig benötigten OFFLINE-Version zu verhindern. Dort „liegt der Hund begraben“!
Doch wie dieses Verhindern (bei WORD usw.) technisch zuzugehen hat, habe ich bisher nicht herausgebracht.
Auf jeden Fall stammt der Eintrag des Ziel-Rechners (…/Users/XWM/… ) von meinem PC mit genau diesem Namen her. Irgendwoher wird er im Zuge des Herunterladens aufgegriffen. Und dann lokal per: file:///C:/Users/XWM/… zur Erzeugung ärgerlicher Links verwendet.
Statt: https://kognik.de/ONLINE/... , so wie es als Pfadanfang von der Mutterdatei her auf dem Server längst bekannt ist, bei deren Los-Senden aber nicht in die „Töchter“-, „Enkel“- und „Urenkel“-Dateien hinein „genealogisch vererbt“ wird!
{Weitere Verhaltens-Tests bei: WINDOWS 10 + 11 / LINUX / APPLE- und anderen Betriebssystemen!! – Jeweils hin zu Tischgeräten, Laptops und Phones.}
----------------------------------------------
Früher war mir mal aufgefallen, dass WORD-Dateien, die „nach einem Absturz wiederhergestellt waren“, bei mir nicht etwa im selben lokalen Verzeichnis landeten, in dem deren Original abgespeichert ist. Die trugen ebenfalls den ominösen Pfad-Anfang: file:///C:/Users/XWM/... . Auch deren interne Hyperlinkpfade waren: durch die Bank „zerschossen“.
Was also müsste man für WORD / Acrobat / LibreOffice / Android / PowerPoint + … in ihren „Speichern-Dialog“ (oder sonst irgendwo) „WO? und WIE?“ eintragen, damit diese Abänderung in beiden Fällen unterbleibt?
Siehe etwa unter: „WORD --- Optionen --- Speichern --- Dokumente Speichern“
die dortigen Vorgaben für Pfad-Anfänge gemäß:
„Lokaler Standardspeicherort für Datei“
oder aber gemäß:
– „Standardspeicherort für persönliche Vorlagen“ ??
{hierfür einen Pfad vorgeben, der sich den Pfadanfang bei der „Mutter“-Datei abholt!}
N. B.: Beide Mal geht es um die „OFFLINE-Neuanlage einer Datei“!
Unter: Formate von Dateipfaden unter Windows-Systemen - .NET
findet sich dazu zwar vieles an Optionen. Mir jedoch sind diese noch unverständlich!
Sodass auch ich selbst „Eine brauchbare Lösung des Grundproblems“ noch nicht kenne.
----------------------------------------------
Zurück zum Original-Problem #1
(„Wenn ich nun die gesamte Word Datei auf mein Handy ziehe und dort dann auf die PDF klicke, tut sich rein gar nichts.“)
Auf meinem / jedem PC ist sowohl die *.doc-Mutter als auch die *.pdf-Tochter dabei auf ein und demselben Gerät gespeichert. Auf dem PC zunächst. Und dort funktioniert der Abruf des Links zur *.pdf-Tochter problemlos.
Nach dem Umziehen aufs Handy sind wiederum die Word-Datei als auch die PDF-Datei auf ein und demselben Gerät gespeichert. Diesmal auf einem Android-Smartphone.
Und da funktioniert derselbe (unveränderte) Link extra überraschenderweise nicht! Obwohl dort keinerlei§?§ Herunterladen von außen her und kein Neuanlegen der *.doc-Datei involviert ist. (Anders§?§ also als in meinem „Website-Fall“.)
Auch da spuckt intern bei der Übergabe des Kommandos von *.doc an *.pdf ein verfälschender Pfad-Anfang dazwischen.
