Voor wat betreft het afdrukken naar scherm van een msds heb ik ook nog een vraagje: sommige medewerkers zijn erg gewend om een afdruk naar scherm te maken (schrm/scr) en deze dan direct te lezen. Dat kan ook omdat er direct een kladblok wordt geopend met de msds. Op het moment dat je de instellingen wijzigt zodat je in html afdrukt dan moet je zelf het bestand opzoeken in je troep-directory. Is het niet mogelijk om de prfile.htm direct automatisch te openen?
Hmm... da's een lastige
Als eerste "Ja, natuurlijk"
Als er een HTML document naar de printer gestuurd wordt, komt ze er op je printer uit, en print je deze naar een file, dan komt ze er in vorm van een PRFILE.HTM uit.
Dit betreft een vrij simpele aanpassing, waarmee ik er op één plek voor kan zorgen dat zodra er naar PRFILE.HTM is geprint, automatisch de Internet Explorer wordt opgestart om dat ding te bekijken.
Echter...
Met dat ik e.e.a. test, kom ik erachter dat het wel eens helemaal geen zin zal kunnen hebben een HTML pagina naar "het scherm" te printen...
Dit moet anders...
Nb: Bij een MSDS is "het probleem" overigens al wel opgelost, daarover zo meer.
Ik zal e.e.a. proberen uit te leggen (misschien wat technisch verhaal) met een voorbeeld + met een "bug" waarvan ik weet dat die nog eens opgelost moet worden:
De DHTML Editor is weliswaar de editor waarin we DHTML teksten intypen, maar de tekst die we maken wordt intern niet als HTML tekst bewaard. Intern wordt e.e.a. als MIME tekst opgeslagen, waarvan de HTML tekst een onderdeel is. Een MIME tekst mag je vergelijken met je Emails in Outlook (Express). Het betreft één bericht met daarin "alles" wat met de betreffende tekst te maken kan hebben. Zo zitten hier bijv. ook "attachments" bij.
Stel, je hebt een TD-Tekst. Je vult je tekst in middels de DHTML editor. In je tekst neem je een Image op (een gevarensymbool of i.d.), die verwijst naar bijv. G:\Images\Gevaar.bmp).
In je editor zie je netjes het plaatje staan. Als je de HTML coding zelf zou bekijken, dan zie je dat er gerefereerd wordt naar
<IMG alt="" hspace=0 src="g:\Images\gevaar.bmp" >.
Helaas kunnen we met dié HTML tekst niet volstaan. Stel dat we de HTML tekst naar een klant sturen, dan zou bij hem géén Image getoond worden, immers "jouw klant heeft geen drive G: met een directory Images waar een file gevaar.bmp in staat". Bij het versturen van een email bericht wordt dan ook iedere verwijzing naar een plaatje omgezet naar "content" van het email bericht. Jouw plaatje wordt a.h.w. als een niet-zichtbare attachment opgenomen in het mailbericht, en je HTML tekst verwijst vervolgens niet meer naar g:\Images\gevaar.bmp maar naar de niet-zichtbare-attachment, ook wel "content" genoemd. Ieder plaatje krijgt zo zijn eigen "Content-Identifikatie" (CID afgekort).
NB: Als je bij een email naar "Bron" zou kijken, dan zie je daar ook deze CID referenties terug (als er plaatjes in je bericht staan).
Mooi. Precies datzelfde wordt ook toegepast bij de teksten die jij registreert. Op die manier wordt je image "gefixeerd" in het bericht. Desnoods gooit iemand het oorspronkelijk plaatje weg, ze is opgenomen als "content" van jouw tekst. Dit zorgt er ook voor dat jij een plaatje vanaf je lokale schijf kan opnemen, en dat deze vervolgens toch op een ander werkstation in de tekst gelezen kan worden; ze is nl. opgenomen in het bericht zelf.
Vervolgens gaan we e.d. bericht opvragen-/wijzigen. De oorspronkelijke lokatie van het plaatje is niet meer bekend, enkel "de naam" (gevaar.bmp). Ook al was de oorspronkelijke lokatie bekend, we zouden het plaatje nimmer mogen terugschrijven naar de lokatie vanwaaruit ze is opgenomen, immers daarmee zouden we wat anders overschrijven. Windows schrijft dit soort files dan weg in de "Temporary Internet Folder".
Nb: Maak maar eens een Word document, mail dat naar jezelf, open het geattachde Word document, en bekijk de bestandslocatie. Zoals je in File001 verderop ziet staat is dat in een tijdelijke folder opgeslagen.
Wij doen dit dus ook, maar dan in de \TROEP directory.
Als je vervolgens de HTML tekst opvraagt (lezen of wijzigen) dan zal alle content weer worden uitgepakt tot een file op disk. Niet in de "temporary internet files" directory, maar in \TROEP. Aldaar kun je konstateren dat er opnieuw een file "gevaar.bmp" wordt aangemaakt. Tevens verwijst je HTML tekst op dat moment naar "\TROEP\gevaar.bmp" opdat je het plaatje kunt zien.
Nou... op zich nog steeds geen probleem, en het printen zou nu ook nog steeds appeltje eitje moeten zijn, ze print gewoon o.b.v. \TROEP\gevaar.bmp.
Echter... en dat is "de bug": Als je nú een HTML tekst opvraagt blijft die uitgepakte content altijd in \TROEP staan. Ok, je kunt zelf die directory leegmaken wanneer je maar wilt, maar doe je dat niet, dan wordt die directory volgegooid met alle content die ooit uit dit soort MIME berichten tot stand is gekomen. Ofwel, maak je \TROEP directory leeg, vraag de TD-Tekst op, ga weer terug naar het Hoofdmenu, en tóch staat de file "gevaar.bmp" nog in je \TROEP directory. Dit hoort natuurlijk niet, immers die \TROEP directory loopt hiervan langzaam vol.
Wat al enige tijd op de stapel ligt om opgelost te worden is dat dergelijke tijdelijk aangemaakte files automatisch weer verwijderd worden zodra je ze niet meer nodig hebt. Ofwel, tijdens de sessie dat je HTML document geopend is, heb je die files nodig, maar sluit je je document (omdat je op Escape drukt, of met F1 savet) dan kunnen ze verwijderd worden.
Vervolgens komen we ergens...
Als we de TD-Tekst zouden printen dan geldt:
a. openen DHTML tekst
b. content kopieren naar tijdelijke files op disk
c. printen document
d. verwijderen tijdelijk aangemaakte files
En we hebben een mooi printje met al onze plaatjes erop.
Maar nu doen we dit "naar het scherm".
a. openen DHTML tekst
b. content kopieren naar tijdelijke files op disk
c. printen document naar prfile.htm
d. verwijderen tijdelijk aangemaakte files
e. automatisch opstarten explorer om prfile.htm te bekijken
Op dit moment bevat je HTML tekst verwijzingen naar plaatjes die inmiddels verwijderd zijn !
Kortom, nú (omdat stap d., het verwijderen nog niet plaatsvindt) zou dit nog even werken, maar als dit probleem is opgelost, werkt het (dus) niet meer.
Merk ook op dat het juist om deze reden is dat bij het genereren van een MSDS de PRFILE.HTM "bijzaak" is. Je zou juist naar de
PRFILE.MHT moeten kijken !
Stel dat jij een email bericht maakt, en de PRFILE.PRN als attachment naar iemand stuurt (buiten Profit om), dan ontvangt deze een HTML document waarin wordt gerefereerd aan plaatjes uit C:\TROEP. Nou, ga er maar vanuit dat die ontvanger niets ziet, want wederom geldt dat die plaatjes er niet zijn.
De PRFILE.MHT betreft echter een zgn. "Web-archief". Dit is een HTML document doch met de opmaak van een MIME bericht. Hierin zitten weer alle attachments, content etc. en dát document kun je wel naar iemand sturen.
Resumer: het bekijken van de PRFILE.HTM zal weinig zin hebben omdat erin aan temporary content wordt gerefereerd die er op dat moment niet meer hoeft te zijn.
Printen van een MSDS bevát al coding inzake het aanmaken van het Web-archief, en ik zal kijken of we daar dié versie niet meteen kunnen tonen.
Dan is je probleem opgelost, maar enkel "voor het MSDS", dus niet voor eventueel andere HTML documenten die je naar het scherm print.
De échte oplossing kon wel eens zijn dat "Printen naar het scherm" de PRFILE.MHT (Web-archief) moet aanmaken...
