Heart-Profit ERP

Material Safety Data Sheet in HTML

Middels de module Profit-Safety-Datasheet is het mogelijk om MSDS-en te genereren. Per heden is hieraan toegevoegd de mogelijkheid dit in HTML te doen.

MSDS in HTML bestaat grofweg uit twee onderwerpen:

a. Het omzetten van de bestaande MSDS in HTML coding.
b. De mogelijkheid om zelf HTML teksten op te nemen incl. plaatjes e.d.

Aktiveren genereren MSDS in HTML

Om een MSDS in HTML op te kunnen bouwen, dient allereerst een hiertoe opgenomen Bedrijfsparameter met "Ja" te worden beantwoord:

(http://www.heartprofit.com/www/transfer/graphics/forum/lopaarwy080131001.png)

Het genereren van een MSDS in HTML dient eigenlijk te worden gezien als een eerste opzet voor een volledig MSDS in HTML. Een klant gaat hiermee expirimenteren, waarbij vanzelf bekend wordt welke funktionaliteit aanvullend gewenst is, danwel anders opgezet moet worden. De verwachting is dat de komende tijd er nog diverse dingen veranderd zullen gaan worden alvorens de funktionaliteit definitief gebruikt kan worden.  Gesteld moet worden dat er vooralsnog geen formeel onderhoud bestaat op de betreffende funktionaliteit voor die klanten die niet zijn "aangewezen" ... ook niet op de gevolgen van het gebruik.

Het genereren van een MSDS in HTML dient expliciet geaktiveerd te worden met bovenstaande bedrijfsparameter.

Genereren MSDS

Via Hoofdmenu,1,3,1,5 (LORTOE) kan een MSDS worden gegenereerd. Hoe een MSDS precies in elkaar zit wordt niet uitgelegd; uitgangspunt is dat de werkwijze van MSDS-en bekend is. Indien een MSDS naar het scherm geprint (zonder HTML) dan ziet ze eruit als :

(http://www.heartprofit.com/www/transfer/graphics/forum/lortoe080131001.png)

Het met Ja beantwoorden van de eerder genoemde bedrijfsparameter zorgt ervoor dat het MSDS wordt opgebouwd in HTML; het document ziet er dan als volgt uit:

(http://www.heartprofit.com/www/transfer/graphics/forum/lortoe080131003.png)

Weliswaar HTML, maar nog steeds kaal.


Style Sheet (CSS)

Als we naar de HTML coding van deze pagina kijken, dan zien we dat ieder soort tekst van het MSDS een eigen Style-Class aanstuurt.

(http://www.heartprofit.com/www/transfer/graphics/forum/lortoe080131004.png)

De volgende Style-Classes worden onderkend:

msds_header1
Eerste regel van de Header van het MSDS.
Bevat tekst welke in een TD-Tekst met de Identifikatie van het Technisch Document is vastgelegd.

msds_header2
Tweede regel van de Header van het MSDS.
Bevat tekst welke in een TD-Tekst met Identifikatie PRDAT kan worden vastgelegd, aangevuld met de datum waarop het MSDS gegenereerd werd.

msds_header3
Derde regel van de Header van het MSDS.
Bevat Artikelnummer + Artikelomschrijving.

msds_customer
N.A.W. gegevens van de (optioneel op te geven) Klant.

msds_footer
Afsluitende tekst van het MSDS.
Betreft de TD-Tekst met de Identifikatie van het Technisch Document + 'EINDE'.

msds_tdr_header
Omschrijving van een nieuwe TD-Rubriek

msds_tdsr_header
Omschrijving van een nieuwe TD-Sub-Rubriek

msds_tdr_text
Tekst horende bij een TD-Rubriek

msds_tdsr_text
Tekst horende bij een TD-Sub-Rubriek

msds_table
Definitie van een Tabel (kwa <div>)

msds_table table
Definitie van de tabel zelf.

msds_table th
Definitie van de tabelheaders.

msds_table tr
Definitie van de tabelregels.

Van ieder van de bovengenoemde Style Classes kan in een Style Sheet worden aangegeven hoe de betreffende class zich moet uiten. Welk lettertype, welke lettergrootte, welke regelafstand, welke kleur, welke achtergrond, wel-/geen borders... noem maar op... In principe de basis om alles aan te kunnen.

Stel dat we deze Style Sheet properties opnemen voor dit MSDS, dan ziet ze er al ineens kompleet anders uit (nb: let even niet op de kleuren, het betreft puur ter illustratie dat alles andere kleuren kan hebben).

(http://www.heartprofit.com/www/transfer/graphics/forum/lortoe080131005.png)

Een Style Sheet is feitelijk gewoon een ASCII bestandje, met een extentie .CSS
De inhoud betreft de definitie van de hierboven genoemde Style Classes, en ziet er uit als :

(http://www.heartprofit.com/www/transfer/graphics/forum/lortoe080131006.png)

Met een paar kleine aanpassingen in de Style Sheet, ziet hetzelfde MSDS er ineens kompleet anders uit, bijvoorbeeld een ander lettertype, of kleur:

(http://www.heartprofit.com/www/transfer/graphics/forum/lortoe080131007.png)


Welke Style Sheet wordt gebruikt?

Printerdrivers zijn uitgebreid met de mogelijkheid te refereren aan een Style Sheet.

(http://www.heartprofit.com/www/transfer/graphics/forum/syptdrwy080131001.png)

Hierbij mag worden verwezen naar een file op disk (netwerk of lokaal), maar er mag ook worden gerefereerd aan een URL (http://).

Wordt er verwezen naar een file op disk, dan zal de inhoud van die (.css) file worden gekopiëerd in het te genereren MSDS; als de inhoud van de .css file achteraf gewijzigd wordt, heeft dat geen invloed op hoe de MSDS getoond wordt, immers een kopie van de Style Sheet zoals die gold toen het MSDS gegenereerd werd, is opgenomen in het MSDS.

Wordt er gerefereerd aan een URL (http:// lokatie) dan zal de Style Sheet gelinkt worden aan die URL. Zodra de inhoud van de Style Sheet in de opgegeven URL wijzigt, wijzigen meteen alle MSDS-en kwa layout mee. Dit kan handig zijn, immers, met terugwerkende kracht kunt U de MSDS-en die in het verleden naar Uw klant verstuurd zijn er anders uit laten zien, omdat de Style Sheet informatie van Uw website wordt gelezen. Wil je niet dat een eerder verzonden document wijzigt kwa Style, dan moet je òf altijd de Style coding embedden in het document (ofwel verwijzen naar een file op disk) òf je zou moeten stellen dat een Style Sheet op Uw website nooit mag wijzigen, maar dat er hooguit een nieuwe bijkomt, en voortaan naar de nieuwe gerefereerd wordt.

Vervolgens is het slechts een kwestie van het Selekteren van de juiste Printerdriver, en het MSDS wordt volgens een kompleet andere Style opgebouwd.


TD-Teksten in HTML

De tweede aanpassing betreft de mogelijkheid tot het registreren van eigen teksten in HTML in plaats van met de Heart-editor. Uiteindelijk zal het de bedoeling zijn om overal de Heart-editor te vervangen door de DHTML editor, vooralsnog beginnen we met de TD-Teksten t.b.v. MSDS.

Nb: Merk op dat we technisch best zouden kunnen toestaan om ook aan een Verkooporder(-regel) HTML teksten te koppelen, maar zolang de overzichten waarop deze gegevens worden afgedrukt (Verkooporder, Opdrachtbevestiging, Faktuur) niet in HTML worde opgebouwd, zal e.e.a. per saldo alsnog geen zin hebben.

Via een nieuw Bedrijfsparametermenu optie zullen we stapsgewijs over kunnen stappen naar het registreren van Heart-editor teksten in DHTML, te beginnen met de Teksten van de Technische Documenten (TD-Teksten):

(http://www.heartprofit.com/www/transfer/graphics/forum/lopatxwy080131001.png)

Indien bovengenoemde parameter aan staat, worden TD-Teksten vanaf dat moment via de DHTML editor bewerkt.

Indien TD-Teksten waarmee via de Heart-editor al teksten waren ingevoerd worden gewijzigd, dan zal deze tekst worden omgezet naar HTML.
Onderstaand wijzigen we bijv. de tekst van de header van het MSDS:

(http://www.heartprofit.com/www/transfer/graphics/forum/sytxhe080131001.png)

Let op:
Het getoonde lettertype Tahoma/3 is puur hetgeen wat in mijn browser als default ingesteld staat. HTML tekst kun je typen als 'ongeformatteerde tekst', in welk geval de tekst wordt getoond in het default lettertype van uw browser, maar je kunt ook expliciet een lettertype selekteren. Wil je dat de tekst in een specifiek lettertype op het MSDS wordt overgenomen, dan moet je expliciet een lettertype selekteren, wil je dat de default gebruikt conform de Style Sheet van het MSDS, dan moet je òf ongeformatteerde tekst gebruiken, òf tekst welke refereert aan dezelfde Style-Classnaam als waar in het MSDS aan gerefereerd wordt. Dit laatste kan echter alleen maar via het Tab 'Bron', en dat is niet handig.

V.w.b. het "pasten" van HTML tekst in het MSDS moet het mogelijk zijn om zelf eigen Style-Class tags aan te maken en aan te sturen. Belangrijk is dat ook dat de juiste Style-Class in het HTML document wordt aangegeven. Maar ja... wat als er nu niets is aangegeven ? Een van de wijzigingen die er aan zit te komen zal vermoedelijk zijn dat de <div> tekst uit het HTML document vertaald wordt naar <div class=msds_header1> tekst zodra het als header wordt afgedrukt. Die vertaling zit er nu niet in.

Als we enkel het de tekst centreren, en een plaatje invoegen:

(http://www.heartprofit.com/www/transfer/graphics/forum/sytxhe080131002a.png)

Ziet het MSDS er als volgt uit:

(http://www.heartprofit.com/www/transfer/graphics/forum/explorer080131001a.png)

De tekst is nu wit, en niet in een oranje kader, omdat deze in het MSDS gepaste tekst niet refereert aan de header class. Doen we dat voor nu even handmatig (via Tab Bron):

(http://www.heartprofit.com/www/transfer/graphics/forum/sytxhe080131003.png)

dan ziet het MSDS eruit als:

(http://www.heartprofit.com/www/transfer/graphics/forum/explorer080131002a.png)

Wat ook opvalt, is dat de msds_header1 style een kader bevat. Die komt nu automatisch om alle drie de afzonderlijke regels te staan;
dat zijn precies de dingen die we bedoelen als we zeggen dat bepaalde dingen anders opgezet moeten worden.
Wat is handig? Wat is beter? Hoe kan het mooier?

Heel Mooi Wouter.

Klein vraag je. Kunnen de teksten ook inspringen, anders wordt de linkerkant zo recht.

Dirk-Jan

komplimenten!

Tuurlijk. Zie handboek HTML.  :wink:

Heel leuk Peter

Maar ik vind dat je best wel een beetje trots kunt zijn op dit stukje werk.

Probeer nu dat zeepfabriekje eens de windows versie aan te smeren. Heb ze al een mailtje gestuurd van dit topic.

DJ

De opmerking over dat handboek is toch wel serieus hoor. En serieus bedoeld ook. HTML is erg omvangrijk, en gaat uiteindelijk nog veel verder dan HTML-alléén ook. Zal ik je eens bang maken voordat je het bier in duikt ? http://www.w3.org/TR/ ... klein beetje naar beneden bladeren naar "Recommendations". Eigenlijk is dat allemaal HTML ... dan snap je ook wat een automatiseerdert doormaakt ...

Om het laatste gaat het niet, maar misschien wel om de complexiteit van zaken als je ze een beetje goed wilt doen. Bijvoorbeeld, de plaatjes die Wouter hier heeft gemaakt gaan niet om het mooie, maar om het krachtige van het concept. Dus, wat niet met zo veel woorden is gezegd, maar wat je met wat kennis van zaken wel al kunt zien is :

Als jij een website hebt, dan heb je -als je alles heel erg goed hebt gedaan- zo'n "style sheet" (CSS) om de layout zaken, lettertypen, kleuren enz. te bepalen. Als je dit heel-erg-goed-gestruktureerd in elkaar zet, kun je in één klap de layout en alles aanpassen, zonder dat zaken door elkaar komen te staan enz. Daarvoor zijn dus die "class" identifiers die domweg refereren naar "layout definities" die elders staan (in de CSS dus).
Als je het nu nog-veel-beter doet, pas je de style van je website aan, en loopt meteen je webshop mee die door derden is ontwikkeld. Vergelijk een website van Lampenier met een webshop van Heart-Profit. Dit "nog-veel-beter" doet zo ongeveer niemand (het is ook te moeilijk c.q. je hebt erg veel kennis nodig), maar die webshop van ons anticipeert er wel op.

Om aan te geven hoe moeilijk het is :
Wat we nu in elkaar hebben gedraaid, werkt met classes als msds_header1 en er is natuurlijk helemaal niemand die in de CSS van zijn website een dergelijke class heeft opgenomen. Die moet daar dus bij komen. Maar is dat wel juist ? nee, eigenlijk niet, want het betreft slechts één van de header definities die in de CSS van de website ook al aanwezig zijn, doch anders zijn genoemd. Redundant zoals dat heet, en dus betekent aanpassen - dubbel aanpassen. En dat was nu net de bedoeling niet.
Die link waar ik hierboven naar verwees, gaat eigenlijk aan alle kanten over de standaards die men moet hanteren, wil je goed met elkaar kunnen praten in deze. Dus, een bepaalde header zal een bepaalde standaard naamgeving kennen, en die is vast ergens binnen W3C gedefinieerd. Als wij die hadden gehanteerd voor de headers in de MSDS, en iedereen deed dat in zijn website ook, dan zou je inderdaad met één wijziging in de CSS alles aanpassen. Let wel, ook je kontakt verslagen, ook je Word dokumenten, ook je emails. Daar zie je allemaal niets van, maar dat komt eigenlijk omdat je het niet weet. Bekijk bijvoorbeeld de Bron-tab van een email maar eens, en zie dat dat hetzelfde eruit ziet als de bron-tab van het plaatje ergens in dit topic.

Omdat toch eigenlijk niemand die standaards allemaal kan behappen, heeft het (kip-ei) geen nut voor ons om ons er aan te houden. Dus, doe maar liever msds_header1 dan iets wat helemaal juist is maar vervolgens niemand begrijpt (het zou dan bijv. HDHD00x1 gaan heten, en sowieso door niemand wordt gebruikt.

Hoe slecht zo'n stellingname toch is, zie je aan de verschillende browsers waarbij de één iets wel kan, en de ander weer iets niet. Dit is ook het eerste wat je overkomt als je "mooie" dingen doet, dan blijkt het in bijv. IE7 niet te werken. Je mag dan ook geen mooie dingen doen, je moet via de standaards werken. En als je dàn mooie dingen blijkt te kunnen doen, merk je dat je vele jaren verder bent :yes:. Zie de link.

Moet ik nog ergens rekening mee houden als ik de bewuste bedrijfsparameter 'Genereren MSDS in HTML' ga omzetten, of kan dat gewoon terwijl iedereen aan het werk is?

Zou niet zo best zijn als iedereen aan het werk is in de Testbestanden  :wink:

Je vraagstelling impliceert dat je dit meteen van plan was te gebruiken in de Produktiebestanden; zou ik niet doen. Testen doen we in de Testbestanden...

De parameter kun je overigens gewoon omzetten als iedereen aan het werk is.

Nb: Omzetten mag van uit- naar aan, maar ook van aan- naar uit; Uitzetten wordt alleen een stuk lastiger als je eenmaal teksten in HTML hebt ingevoerd, immers, die worden enkel (juist) getoond als het MSDS ook in HTML wordt opgebouwd.

Wat dat betreft dus: eerst in test wat spelen, testen met css, welke kleurstellingen, lettertypes etc., en pas als alles akkoord is, de boel in produktie aktiveren.

Oké, dan gaan we later deze week wel testen in de testbestanden...

Hier dan de eerste testresultaten:
(http://www.schaepman.nl/2006/pdflibrary/images/MSDS_Screen.png)

De link naar de volledige MSDS:
http://www.schaepman.nl/2006/pdflibrary/VWS/P2D000098.HTM

Ik vind het nog moeilijk om de tabellen op een goede manier te laten weergeven. Ik zou bijvoorbeeld graag de tabellen over de breedte van de pagina willen spreiden en de cellen lichtgrijs willen maken. Als ik de tabel lichtgrijs maak met background in de css, dan worden niet alleen de cellen grijs maar ook het gedeelte van de pagina aan de rechterkant.

In dit voorbeeld heb ik geen klantnaam ingevuld. Als ik dat wel doe, dan krijgt dit een gedeelte een class=msds_tdr_header mee. Dit betekent dat de opmaak hetzelfde wordt als de hoofdstuktitels, in dit geval met een groene achtergrond (niet zo mooi). Het zou misschien handiger zijn om deze onderdelen los van elkaar te kunnen aansturen.

Ik ben met de afbeelding bovenaan bezig geweest, waarbij ik diverse keren de afbeelding heb gewijzigd. De afbeelding heb ik telkens in c:\troep neergezet. Nu blijkt dat profit telkens een afbeelding in c:\troep maakt met dezelfde naam met nog wat tekens er voor (_2al0tbbc3-schaepman_logo6.gif) en dat dan voor alle afbeeldingen die zijn gebruikt, dat zijn dus inmiddels telkens 6 bestanden...

Niet te geloven ... Mooi hoor !


Komt goed.


Dit deel hoort bij Wouter (die even ziek is), en herken dit van het opnemen van plaatjes in Brieven / Kontakten. Zo heb ik zelf inderdaad honderden van die dingen in mijn \TROEP staan. Ik kan op dit moment niet zeggen wat het nut van het bewaren ervan is, en kan hooguit aangeven dat dit nodig is als tijdelijk "medium" voor plaatjes die op een bepaalde manier (!) in de tekst worden ingehangen. Is een beetje het verhaal wat Wouter eerder schreef (maar dan andersom) : als jouw css lokaal staat, dan zal ze ingekopieerd moéten worden.
Nu ik er zo over nadenk ... volgens mij is het verhaal andersom : wil je zelf zo'n plaatje kunnen zien, dan moet ze eerst ergens worden opgeslagen. Dit zou dan te maken moeten hebben met het proces van het werken in de DHTML Editor, en het dan zelf kunnen zien van het plaatje terwijl het niét is ingekopieerd a.g.v. de wijze waarop jij dat hebt ingehangen. Later, als de MSDS wordt gegenereerd vindt ook weer een "bijzonder" proces plaats, want dan moet zo'n plaatje weer worden ingekopieerd. Best ingewikkeld allemaal.

Als Wouter er weer is weet hij vast iets zinnigs te vertellen (ik niet dus), dan wel er iets aan te doen indien mogelijk.


Pas in elk geval op voor "trucjes" die dan in jouw browser wel werken, maar elders niet. Ofwel, je moet de gangbaren aan boord hebben om het te testen.
Wat je wil kan vast wel, maar met de opmerking dat als jij weet hoe het moet, je eventueel aan ons moet aangeven wat er zou kunnen veranderen om het "echt" of "echt makkelijk" te laten werken. Zoals al wel eerder gezegd, dit is een voorzet waarvan wij denken dat het voldoende kan zijn, maar zonder de werkelijke ervaring.

Hey BKienhuis, ziet er prima uit ! En dat voor een eerste beginnetje  :wink: Ben benieuwd waar dat eindigt.


Komt omdat de DHTML editor een HTML editor is, en geen Mime editor.

Dit vereist inderdaad wel wat meer uitleg om het te kunnen begrijpen...

De editor waarin je nu werkt is een DHTML editor. Alles wat je intypt wordt dus feitelijk een HTML bericht, en daarin heb je de mogelijkheid aan images te refereren, via een src=<drive:>\<dir>\<filename> konstruktie. Bij het MSDS in HTML heb ik hetzelfde uitgangspunt genomen als bij de Kontakten-/Mailberichten: eventuele referenties (images) behoren als Embedded Content in het bericht te worden opgenomen, immers, wie zegt dat het plaatje er nog staat tegen de tijd dat iemand anders het verslag opvraagt?  Of, hoe anders zorg je ervoor dat jij kunt refereren aan een plaatje op drive c: en zodat iedereen dit toch kan zien?

Daarmee komt vervolgens een klein probleem om het hoekje... Embedded Content tref je niet aan in een normaal HTML bericht; wel in een Mime Bericht (*.EML documenten, krijg je als je een email bericht opslaat (Opslaan Als)). Zodra iemand een DHTML verslag maakt en daar een plaatje in opneemt, wordt dit plaatje bij het saven hieruit gelezen, vertaald naar Embedded Content, en opgenomen in het bericht. Als iemand het verslag weer wijzigt, tsja... dat kan 10 seconden later zijn, dan kan ook een jaar later zijn, het kan op een andere pc zijn etc. Ofwel, uitgangspunt moet zijn dat die image er dan niet meer is. In het Mimebericht zal de image zijn vertaald naar Content-Id, en in je HTML bericht (View Source) zie je dat je "src=" regel verwijst naar "cid:<content-Id-referentie>". De DHTML editor is echter een HTML editor en geen Mime editor; ze herkent deze "cid:" referentie niet. Derhalve wordt bij het opvragen van het bericht de Embedded Content weer vertaald naar een echte image (in de \troep directory) en wordt de cid: referentie weer vertaald naar die image in \troep. Op die manier zie je toch het plaatje.

Vergelijk e.e.a. maar met de wijze waarop dit normaliter ook gebeurt als je bijv. een attachment uit een mailbericht opent; Windows slaat deze op in ..\Temporary Internet Files\<temp dir.>\<filename> en dit blijft daar veelal net zolang staan tot het er een limiet bereikt wordt. Zoiets hebben we in Profit (nog) niet, maar zou in principe ook niet nodig hoeven te zijn. Alles wat in de \TROEP directory staat is "troep", en feitelijk zouden we bij het opstarten van Profit deze hele directory leeg mogen maken. Omdat wij hier meerdere Applikaties hebben draaien (die met dezelfde \TROEP directory werken) doen we dat toch maar even niet, en uiteindelijk blijven al deze bestanden staan. Neemt niet weg dat je zelf zo af en toe al die files gewoon kunt verwijderen...

Bij het MSDS in HTML wordt het nog een tikkie lastiger, immers, daar wordt één HTML document gegenereerd uit een variabel aantal andere (mogelijke HTML) teksten. In theorie kun je meerdere TD-Teksten gedefinieerd hebben, met beide daarin een image genaamd 'scherm1.jpg', doch waarin in beide gevallen scherm1.jpg een totaal andere inhoud bevat. Toch moeten beide images met hun juiste inhoud tot uiting worden gebracht in het MSDS document. Dit is de reden dat de Embedded Content bij het MSDS in HTML wordt voorzien van een unieke naam, bijv. "_2aj0kigbm". Ik heb er echter voor gekozen om niet enkel deze unieke naam te gebruiken, maar dit als voorvoegsel op de oorspronkelijke naam te gebruiken, opdat je, bladerend door View Source, of door de \TROEP directory, toch nog enig inzicht hebt in welk plaatje waar staat. Dit dus v.w.b. dat voorvoegsel op de imagenaam.

Er is ook nog een kombinatie tussen HTM en EML (Mime) en dat is een bestand met een extentie MHT (Web-Archief). Een Web-archief kun je maken door een internet pagina op te slaan als Web-archief. Zo'n Web-archief is eigenlijk hetzelfde als een Mime bericht, hooguit ontbreken de gegevens die te maken hebben met het emailen op zich. Middels een MHT document ben je in staat om een HTM pagina te maken en daarin de images te embedden als content. Het MSDS in Profit wordt ook op deze manier opgebouwd, immers, zouden we dat niet down, dan heb je (slechts) een HTML document welke verwijst naar images als src="c:\troep\_2aj0kigbm-heartprofit.jpg". Verstuur de PRFILE.HTM naar iemand anders, en niemand kan dit lezen, omdat het plaatje niet gevonden kan worden. Ook al had je gerefereerd aan een plaatje op een netwerkdrive, dan zouden anderen in jouw netwerk dit  nog wel kunnen lezen, maar buitenstaanders niet. Hier dus de noodzaak e.e.a. te embedden als content.

Tja, op zich vond ik het inderdaad logisch dat de afbeelding als 'temporary file' mee komt, alleen dat dan ook alle vorige versies mee komen...ik kan nergens achterhalen waar deze vandaan komen.

Ik ben met de tabellen al wel weer ietsje verder, alleen moet ik daarvoor handmatig wijzigingen doorvoeren, misschien dat jij daar wel iets voor weet. Ik heb in de stylesheet dit toegevoegd:
#tabel {
   width:      85%;
   margin-left:   70px;
}
Daarna heb ik in de htm-file een id toegevoegd bij de tabellen:
<div class=msds_table><table id="tabel" border=1><tr><th align=left>Naam</th><th align=right>Conc.bereik</th><th align=left>CAS-no.</th><th align=left>EINECS-no.</th></tr>
De tabel is nu geplaatst in lijn met de tekst (inspringen vanaf linker kantlijn) en de breedte is in te stellen (in dit geval 85%). Het komt er dan zo uit te zien:
(http://www.schaepman.nl/2006/pdflibrary/images/20080211msds_screen1.png)

De vraag is dan wel: hoe krijg ik een id aan de tabellen waarmee ik vervolgens de layout heel makkelijk kan veranderen?

Iedereen keer dat je het MSDS in HTML genereert kriigen deze images een nieuwe naam; de tekst verwijst immers naar 'scherm1.jpg' en die naam wordt bij de opbouw van het MSDS uniek gemaakt. 2 MSDS sen genereren en er is 2x een unieke filename toegekend. Nogmaal, eigenlijk moet het mechanisme van zichzelf weten welke filenames er tijdelijk gebruikt zijn, en moeten die verwijderd worden.

Wellicht nog beter: net als dat er in Windows bij 'Temporary Internet Files' een unieke directory verschijnt, zouden we per Profit sessie een Subdirectory kunnen maken in de \TROEP directory en dáár al temporary files in kunnen zetten. Bij het afsluiten van de Profit sessie zou dan de hele directory verwijderd moeten worden. Zou je echter maar 1 sessie tegelijkertijd (kunnen) hebben, dan is dit hetzelfde als de huidige Troep directory.

Als je de \TROEP directory nu maar als "troep" ziet, dan interesseert het je niet eens wat er in die directory staat; als wij die directory 'hidden' en ergens in 'document & settings\local settings' hadden opgenomen, had je er nooit naar gekeken.

Misschien zit het verschil hem wel in het feit dat er in die directory ook output van printoverzichten (PRFILE.PRN /.XLS/.HTM) wordt opgeslagen, en dat "minder troep" is dan de temporary files zoals in deze teksten.

Ik ga even voor je kijken...
:17c:

Ik vond het op zich al wat vreemd "waarom dit niet (meer) zou werken".
Ik had zelf al wel getest met kolommen, en kon tabel, header, en regels los van elkaar indelen; zie:

(http://www.heartprofit.com/www/transfer/graphics/forum/explorer080211001.png)

Ik zie ook al waar het mis gaat: mijn eigen tekst is onjuist  :(

V.w.b. onderstaande 3 regels dient de _ na "msds_table" te worden verwijderd !
(Heb de oorspronkelijke tekst inmiddels aangepast).

msds_table table
Definitie van de tabel zelf.

msds_table th
Definitie van de tabelheaders.

msds_table tr
Definitie van de tabelregels.

100% zeker weet ik het niet, maar het lijkt erop alsof e.d. tag neerkomt op 'een tabel binnen de definitie msds_table'.
th is dan voor de table header, tr voor de table rows, en er zullen (automatisch) vast nog meer zaken op deze manier mogelijk zijn.

Nb: De door mij gebruikte table definities vind je in attachde css.

Ja, da's natuurlijk nog een betere oplossing. Werkt bij mij ook zoals het hoort inmiddels.

Mooi.

Wel laten zien heh ! :clapping:

De kolommen ?
Hoe je die moet aansturen weet ik ook niet. :swoon:

Ik heb hier een nieuwe versie neer gezet:
http://www.schaepman.nl/2006/pdflibrary/CEPE/20080211P2D000098.HTM (http://www.schaepman.nl/2006/pdflibrary/CEPE/20080211P2D000098.HTM)

Aan de kleuren e.d. wordt nog wel gewerkt, binnenkort gaan we er wel eens over vergaderen. Kolom breedte moet wel gestuurd kunnen worden dmv COL elementen maar het fijne weet ik daar ook nog niet van. Ik heb ondertussen wel een boek besteld over CSS...

Als je naar onderstaand stukje kijkt, zie je enkele zaken in onbalans; extra regel voordat een nieuwe rubriek begint, en extra regel voordat tekst onder een rubriek-header begint;

Is dat onze schuld denk je ?

Da's wel iets om uit te zoeken: misschien een stukje inrichting van de msds?

Zou het iets te maken kunnen hebben met 'lege regels' in het document?

Ja tuurlijk. Maar dan zou jij die lege regels op de betreffende plaatsen ook moeten herkennen;
Voor zover ik weet worden lege regels (aan het eind, en natuurlijk sowieso aan het begin) onderkend als "nuttig".
Merk nog op dat in de Dos editor lege regels aan het eind niet konden bestaan (volgens mij), maar dat deze denkelijk in de eerste naar-HTML konversie in de HTML editor wel ontstaan kunnen zijn. Als dit indferdaad zo is, kun je ze aldaar verwijderen. Let wel, dit behoort dan eenmalig te zijn (als het al zo is).

?

Om in Dos een lege regel afgedrukt te krijgen moest je een spatie zetten.

Echter niet middels de space-bar maar via alt-255
Op deze manier doen wij dat bij SE

Dirk-Jan

Ik heb nog even gekeken naar die extra lege regels: hieronder staan de stukjes html die bij de voorbeelden horen:
(http://www.schaepman.nl/2006/pdflibrary/Images/2008021501.png)
(http://www.schaepman.nl/2006/pdflibrary/Images/2008021502.png)
Eerlijk gezegd kan ik nog niet precies achterhalen waar de fout nu zit. Ik heb geprobeerd om de TD-tekst 'IMD' (hoort bij 'IMDG code:') eens met de DHTML editor te bewerken maar dit gaat nog wat lastig omdat er dan weer niet standaard een header voor komt. Ook viel het me op dat de ingevulde waarde ('3') dan ineens niet meer op het document komt. Ik heb de productiebestanden opnieuw naar testbest gekopieerd en nu werkt dat wel weer gewoon.

Het is trouwens wel leuk dat je nu met relatief weinig veranderingen een compleet nieuw uiterlijk aan de msds kan geven:
(http://www.schaepman.nl/2006/pdflibrary/Images/2008021503.png)
http://www.schaepman.nl/2006/pdflibrary/CEPE/20080215P2D000098.HTM (http://www.schaepman.nl/2006/pdflibrary/CEPE/20080215P2D000098.HTM)

Is aangepast; zie http://ha1.heartprofit.nl/profit/index.php?topic=19678.0

Overigens nog 2 dingen aangepast:

a. http://ha1.heartprofit.nl/profit/index.php?topic=19679.0
b. http://ha1.heartprofit.nl/profit/index.php?topic=19680.0

Ik neem aan dat hiervoor een upgrade nodig is?

Vast niet  :wink:

Wilde het al overzenden, maar er kwam iets tussendoor. Zal dit zodadelijk doen. Modem staat toch wel klaar he?

Bwah... niet dus  :(

Geef even een gil als ik erbij kan.

Staat klaar inmiddels...

Ok. Thx. Even wachten nog... ik ben nu nog even aan het kijken naar het elimineren van de lege regels na headers etc.
Dat krijg je vast ook wel via de Style Sheet voor elkaar.

Overgezonden. Inklusief eliminaties van lege regels na de overgang van Rubrieken-/Subrubrieken.
Het lijkt me dat dat via de Style Sheet ook geregeld moet kunnen worden.

Ik stuur je zo even een e-mail met nieuwe prnfile.htm, volgens missen er wat classes.

Opgelost, en tevens nog wat zaken:

1. http://ha1.heartprofit.nl/profit/index.php?topic=19687.0

2. http://ha1.heartprofit.nl/profit/index.php?topic=19686.0

3. http://ha1.heartprofit.nl/profit/index.php?topic=19682.0

Feitelijk komt het eropneer dat nu alle lege regels verdwenen zijn, tenzij je die zelf expliciet definieert d.m.v. het opnemen van definities "LEEG".

(http://www.heartprofit.com/www/transfer/graphics/forum/lofkra080215001.png)

Ik ben nog weer een probleempje tegen gekomen. Het afdrukken van de msds gaat nu best goed (nog steeds in testbest) alleen blijkt nu dat de waarde voor vaste stofgehalte in rubriek 9 telkens op 100% staat (onterecht). Dit gebeurt bij elk product. Als ik in prodbest een afdruk maak staat daar wel de juiste waarde op.
Is het verder mogelijk dat de opmaak van de getallen die in rubriek 9 komen wordt beïnvloed? Bij de soortelijke massa staat bijvoorbeeld 1,333 (met een komma), bij vaste stofgehalte staat 100.000 (met een punt). Op de msds is één decimaal nauwkeurig wel goed genoeg.

Om even uit te sluiten dat het niets met de MSDS in HTML te maken heeft; zou je de parameter 'MSDS in HTML' eens uit kunnen zetten en dan opnieuw het MSDS genereren. Wat staat er dan op? Ook 100%? Zo ja, dan zal het aan instellingen in de testbestanden liggen. Als er dan wel iets anders staat, zou het met de HTML versie te maken moeten hebben.

Als ik 'MSDS in HTML' uit zet blijft het vaste stofgehalte op 100% staan, zal dus inderdaad iets in de testbestanden zijn. Die had ik vorige week nog gekopiëerd van productie naar test dus je zou zeggen dat dat redelijk overeen zou moeten komen.

Kan het zijn dat de Bedrijfsparameter Default Vaste Stof Gehalte Artikel (Bedrijfsparameters Artikel Beheer, Blad-4) in de Testbestanden op 100 staat?

Inderdaad, deze stond op 100: weer wat geleerd :thankyou:

Niet noodzakelijk  :(

Als je Produktie- naar Test kopieert, dan kopieer je feitelijk de hele Produktiedatabase over de Testdatabase heen. V.w.b. SY hebben we maar 1 dataset (daar hebben we geen gescheiden Test- en Produkie). Diverse parameters worden echter opgeslagen in deze Systeembestanden, en ook al kopieer je LOPF naar LOTF en ADPF naar ADTF, dan kopieer je daar nog niet deze parameters mee !

Middels Hoofdmenu,9,5,6,2 kun je dit soort parameters van Produktie- doorkopieren naar Test.

Die optie dus uitvoeren om ook alle parameters in Test gelijk te krijgen aan wat er in Produktie staat. :wink:

Nog een opmerking hierbij : Wèlke Parameters op Wouter's manier moeten worden gekopieerd kun je niet zien. Dat ook altijd uitvoeren dus.

Kan er ook nog iemand antwoord geven op het tweede gedeelte van mijn vraag:

:22c:

We zullen er in ieder geval voor zorgen dat voor alle Standaard Elementen een komma gebruikt wordt. Om alle getallen standaard af te ronden op 1 decimaal lijkt me niet erg handig. Het gewenste aantal decimalen zou iedere klant voor zich per Standaard Element aan moeten kunnen geven. Hiertoe zou bij Toevoegen/Wijzigen Standaard Elementen een Rubriek "Aantal Decimalen" beschikbaar moeten komen. Tevens zal het genereren van de MSDS hierop aangepast dienen te worden. Totaal 5½ uur.