Heart-Profit ERP

vandaag voor eerst na update een msds uitgedraaid.
Nu is de opmaak compleet verandert..........
Volgens mij is de tabel van hfdstk 3, samenstelling van de bestanddelen niet goed meer (misschien te maken met weergave reach registratie nummer?)

zie bijgaand txt bestand

ook zie ik dat scheiding tussen hoofdstukken waar geen pagina einde is weer gegeven word door een 2 met een dakje erop.

Ik kan zien dat de tekst "puin" wordt in hoofdstuk 3. Daar kan ik naar kijken.

Maar wat je met een 2 met een dakje erop bedoelt ??

Geef maar een bericht wanneer je modem klaar staat, want deze neemt niet op.

staat klaar (denk ik)

Zoals tel. toegelicht bedoel je hier de ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ  mee die in je PRFILE.PRN getoond wordt.

"Niets nieuws", hier werd (in DOS) altijd een doorgetrokken lijn getoond (Character 196), welk character in Windows gewoon niet ondersteund wordt. D.w.z., niet door je Windows editor, niet door "MS-Word" waar je je MSDS in kopieert (zoals tel. aangegeven). Nu dacht ik dat het wél door de Printer ondersteund werd (mits die conform MS-DOS 850 print), maar als ik het MSDS print, krijg ik die ÄÄÄÄÄÄÄÄÄÄ tjes ook op de print te zien (hmm, heb ik me daar vergist? er staat we wel iets van bij dat bij financiële printjes het balans-staartje ook niet juist geprint werd in Windows).

Vooralsnog ga ik er dan maar even vanuit dat zo'n character inderdaad niet ondersteund wordt, en zal ik i.g.v. Windows een ander character gebruiken. Blijkt echter later dat vanuit Windows zo'n CHR(196) wel degelijk als doorgetrokken streep op de printer terecht moet kunnen komen, dan zal e.e.a. weer terug moeten worden gezet, omdat we feitelijk met deze aanpassing het MSDS van iedereen aanpassen (en het wel bedoeld is om te printen, en niet om via knippen-/plakken in Word op te nemen; e.e.a. wordt dus nu aangepast omdat de ÄÄÄÄÄÄÄÄÄÄ op je print terecht komt, en niet omdat het in de editor zo getoond wordt).

Het verhaal krijgt waarschijnlijk nog even een andere wending...

Dit, n.a.v. het feit dat Nic Vaessen Off Topic aangeeft "dat dit wel altijd gewerkt heeft", ook vanuit Windows.

Als eerste even mijn "het gaat om wat er op de print staat".

Stel dat ik een MSDS vanuit DOS print, en de PRFILE.PRN inlees met de (DOS) Roeleveld Editor, dan zie ik (netjes) een doorgetrokken streep (zie figuur 1). Lees ik precies diezelfde file in met Notepad, dan zie ik daar ÄÄÄÄÄÄÄÄÄÄÄÄ (zie figuur 2). Notepad herkent dat teken niet, maakt er wat anders van, maar als je het naar de printer stuurt, dan komt er toch weer een doorgetrokken streep uit (mits die printer maar in MS-DOS 850 wordt aangestuurd, en daarmee vergelijkbaar is met de Roeleveld Editor).

Als hetzelfde MSDS vanuit de Windowsversie geprint wordt, dan zien we een Z met een omgekeerd dakje (zie figuur 3, en dit is wat NV met 2 dakje bedoelde). Bekijken we dié versie in DOS, dan zien we geen doorgetrokken streep meer (zie figuur 4), en derhalve gaat het ook op de printer verkeerd.

Toch is de koding die e.d. streep afdrukt niet gewijzigd, en ook de Systeemprogrammatuur inzake de afhandeling van prints (welke sinds 2006 koding bevat om te printen tekst te konverteren vanuit de Windows Codepage 1252 naar een instelbare Codepage, welke 850 behoort te zijn).

En... bij dat laatste blijkt e.e.a. nu fout te gaan !

Frappant is dat als de konversie van de Codepage niet plaatsvindt, de ÄÄÄÄÄÄÄÄÄÄ  netjes als doorgetrokken streep eruit komt; maar ja, die koding zit er al sinds 2006 in, dus, strijkt niet met "gaat sinds de upgrade fout".

Wat ook opvalt, is dat als er gekonverteerd wordt van Codepage 1252 naar Codepage 0 (i.p.v. 850), e.e.a. er ook netjes als een doorgetrokken streep uitkomt. Nu is de Codepage instelbaar via een parameter, en nu is het zo dat die bij jullie niet is ingevuld (en dus op 0 staat), maar de koding haalt die parameter pas op zodra ze <> 0 is.

Enfin, mijn gedachte was ook niet voor niets dat zoiets wel goed op de printer uit zou komen maar niet in notepad (en wat aan notepad ligt, zie 1 <> 2), maar nu komt e.e.a. dus al niet goed uit de printer, terwijl ik in theorie kan verklaren waarom dat dat veroorzaakt zou moeten zijn door een Codepage die op 0 staat, alleen, dat krijg je niet ingesteld. Ik kan dus nog steeds even niet verklaren wat dit dan veroorzaakt zou moeten hebben...

Alles invoeren zonder CodePage en dan nu gebruiken mèt ?

Wat bedoel je daarmee? Die doorgetrokken streep wordt nu vanuit koding weergegeven.

Feit is wel dat vanuit koding een CHR(196) wordt weergegeven, en dat vanuit DOS/WIN gebeurt, waar CHR(196) in WIN een totaal ander teken is, en zodra die teruggekonverteerd wordt, de Ä oplevert (wat eigenlijk wel logisch is).

Dus, het konverteren van de 1252 naar 850 lijkt me op zich terecht, en zal zijn opgenomen om een "ü" welke in Windows een characterwaarde 252 heeft, te vertalen naar DOS, alwaar het characterwaarde 129 wordt. Evenzo wordt "ö" vertaald van 246 (WIN) naar 148 (DOS). Maar, CHR(196) vertalen naar DOS, levert 142 op, wat de Ä is, terwijl juist die CHR(196) een DOS character eerst, en eerst naar WIN vertaald zou moeten worden, ware het niet dat er in WIN geen geldig teken voor bestaat. Hoe dan ook, we zouden op e.o.a. moeten herkennen dat het keihard om de weergave van een CHR() code gaat, en in dat geval geen CPCONVERT moeten toepassen of i.d.

Nog steeds verklaart dat niet waarom het bij BC voor de Upgrade wél goed ging.

Ik ga nu proberen te bepalen (a.h.v. geblokkeerde funkties) om te kijken of de Public waarde van de Codepage bij hun toch niet op e.o.a. manier op 0 gestaan kan hebben (in welk geval de streep het wel gedaan zal moeten hebben, maar de ö, ï, ü etc. weer niet).

 :offtopic:
Het hele verhaal wordt in middels wel een beetje technisch, en is wellicht niet voor iedereen te volgen, maar ik verkies er toch even voor om het hier via het forum te laten  verlopen. Dit, opdat de thuiswerkers ook kunnen meedenken, en opdat we e.e.a. nog eens kunnen nalezen.

Geblokkeerde funktie uit 2009 (voor de niet uitgevoerde upgrade van oktober 2010) toont aan dat toén reeds Codepage gewoon op 850 stond, en niet 0 was.

Ehh ... programmatuur op een Novell server saven met Codepage 850, terwijl het intussen op een Windows server staat ?

of

Programmatuur inlezen met een andere editor dan voorheen die Codepages kan saven terwijl dat voorheen niet gebeurde (en 850 impliceerde) ?

Volgens mij moet je dit helemaal nooit gaan proberen te begrijpen. Lees je eigen vorige post - en vergelijk dat met de roemruchte config.weetikveel tekst van mezelf. Begrijpt ook niemand.

Maar :

Kan het nou worden opgelost of niet ?

De editor met welke e.e.a. hier is ingelezen doet er niet toe, omdat het niet het character is wat is het programma staat, maar er wordt keihard een CHR(196) gesayd.

SYST7 converteert iedere tekst vanuit Codepage 1252 naar 850, en deze CHR(196) was al een DOS character, en zonder deze eerst naar een Windows character te vertalen (wat in dit geval niet kan, omdat er geen windows variant is), mag ze niet naar DOS terugvertaald worden (het is al een DOS character).

M.i. kan het worden opgelost, en wel als volgt:

In SYST wordt de oorspronkelijke tekst die weergegeven moet worden bewaard (daarin staat REPLICATE(CHR(196),89)). Wat ik nu wil gaan doen, is in SYST7 inbouwen, dat zodra er vanuit coding een CHR() opdracht gegeven wordt, deze niet via CPCONVERT wordt terugvertaald vanuit 1252 naar 850.
Daarbij anticipeer ik er maar even op dat áls er een CHR() opdracht gegeven wordt, die hele SAY niet vertaald mag worden.

Hoewel ik denk dat dit oplosbaar is, kan ik niet verklaren waarom het "voor de upgrade" bij BC wel goed zou moeten zijn gegaan...

Ik weet niet of het wel zo simpel is (dan wel zo simpel kan worden verklaard);

- Volgens mij zit je te kijken naar e.o.a. ascii bestand, met maar even de vraag welke code page daar aanhangt.

- Wat mij betreft veranderen er "Unicode" zaken in Windows (updates) zelf, en of die veranderingen altijd zo goed zijn vraag ik me af (of ze zijn gerelateerd ook natuurlijk).

- Zaken met Notepad bekijken moet je al nooit doen (ik zeg het maar even).



Had je zeker nog geen antwoord op ? haha, zie boven. Maar goed, ik zeg niet dat ik het kan volgen hoor. Als je maar oppast dat het niet straks hier werkt, bij hun nog steeds niet (maar anders) en verder ook nergens meer.

Ik zei al : je moet het niet proberen te begrijpen. Lukt je toch niet want er komt te veel bij kijken en er zit te veel tussen;
Als ik een leuk tekstje copy paste van een email in Profit, en dat vervolgens naar een PDF print komt er ook iets anders op papier te staan. Nou ja, voor één raar kringelding wat ik ken. Geen idee.

In dit geval is het misschien een beter idee om te bewijzen a.d.h.v. een oude versie of het daar (nu) net zo eruit komt, of dat die het toch nog deed. IK bedoel : niets veranderd is niets veranderd, en als je dan nu wat verandert kan je er vanuit gaan dat het elders niet meer werkt. Tenzij je het 100% doorgrondt, en dat ga ik vooralsnog niet geloven (maar kan wel natuurlijk -> na hoeveel tijd ?).

Dat 1e had ik i.d.d. nog niet op gereageerd, daar ga ik nu zo mee verder.

V.w.b. het 2e. I.d.d., in Notepad moet je e.e.a. niet bekijken.

Wel vertalen we alles naar een Codepage 850, en dus zou e.e.a. in de Roeleveld Editor goed moeten staan, en op iedere printer die volgens de codepage MS-DOS 850 is ingesteld (onze standaard drivers).

Probleem is bij deze opgelost.

In figuur MSDS1 staat zoals de print er nu uit komt te zien als we hem met de Roeleveld Editor inlezen. Ik heb de Omschrijving van het Artikel ook even expliciet gewijzigd, opdat we daar de ä, ï, ö in tegenkomen. Alles ziet er hier verder prima uit.

In figuur MSDS2 (beetje donker), zien we hoe e.e.a. er op de printer eruit komt. Precies hetzelfde zoals de Roeleveld Editor. Goed, conform Codepage 850.

Figuur MSDS3 toont echter wat er gebeurt als we die file in Notepad inlezen, en inderdaad, dat moeten we niet doen, immers, dat is een Windows programma die Codepage 1252 zal verwachten terwijl de Codepage juist is opgemaakt conform 850.

Ok.


Niet helemaal waar, want Unicode zit daar ook nog tussen. Nou ja, soms. Per land anders - weet ik veel. :smile:

En printen naar een PDF, werkt dat ook nog ?

Trouwens, voordat je denkt dat het *echt* werkt, je "Schoonmaakmiddel" ziet er niet helemaal meer uit zoals het hoort ...

Vast wel weer verklaarbaar. Maar zo uit de losse pols : niet door mij.
(jaja, zal wel een test zijn van jezelf -> mislukt dus ?)

Edit : lamaar. Te veel naar Notepad gekeken. :smile:

Nic, het eerste deel is nu ook opgelost.

Probeer het nog maar eens  :smile:

NB: Modem mag weer uit.

Hoi wouter,

Ziet er weer potent uit. :smile:

Dit zeggende ben ik er wel van overtuigd dat de doorgetrokken lijn  in het verleden een rij van minnetjes was.  :wink:

desalniettemin Opgelost

even "naast" deze post:
Jij vermeld de inhoudsstoffen nog in rubriek 2
Dat hoort nu in rubriek 3 te zijn en per 01/12/2010 ben je hiermee in overtreding.

Check de huidige indeling volgens de laatste versie van REACH bijlage II in het document EC 453/2010 mbt de nieuwe SDS eisen (is geen richtlijn meer maar een verordening, dus format is nu vastgespijkert)

zie hier de wettekst
http://eur-lex.europa.eu/JOHtml.do?uri=OJ%3AL%3A2010%3A133%3ASOM%3AEN%3AHTML (http://eur-lex.europa.eu/JOHtml.do?uri=OJ%3AL%3A2010%3A133%3ASOM%3AEN%3AHTML)

of anders even google op EC 452/2010 ...