[Allegro] Probleme: Win10 (Version 1809 -sic) Fonts werden nicht akzeptiert. a99.exe läuft nur mit normalo-Fonts(arial)

Di Okt 16 11:45:52 CEST 2018

Guten Tag Herr Eversberg,
Danke, daß Sie sich dem dringenden Problem angenommen haben.

Ihr "Workaround" funktioniert wahrscheinlich am besten, bei
denjenigen, die ein "normales" allegro ohne große Änderungen in der
cfg und frm haben. Dieses ist bei mir leider nicht der Fall.

Deshalb gestatte ich mir, meinen "Workaround" (=blödes Wort)
vorzustellen.
Dazu info:
1. meine cfg ist strikt alpahabetisch sortiert. bei einer doch größeren cfg
findet man sonst nix auf die schnelle. Tja, was ist aber "alphabetisch"?
z.b. sowas:
#80
...
#89
#8a
...
#8z
wenn man sich die asciiliste anschaut, ist meine sortierung nicht ganz
falsch ;-)
zuerst Ziffern, dann große buchstaben und dann kleine buchstaben.

2. die frm könnte man zwar ähnlich (in der abfrage) alphabetisch
aufbauen, aber es wäre NICHT komfortabel in der abfolge der
nötigen(gewohnten) arbeiten eines bibliothekars ;-)
also, ist die frm selten sortiert.

nun zum workaround:
in der abteilung meiner frm, die die RDAinhalte abfragt, habe ich
zuoberst #99g "#99g"PlaceboInhalt reingesetzt. sodaß es jetztg so
aussieht:

[Buch, Teil 2]
#99g"#99g"PlaceboInhalt
#73.1 "erweit. ErschAngabe."
#0c.1 "Inhaltstyp"|Vctype
#77.1 "Datentr.Typ"|Vmtype

wichtig ist dabei: ich nehme mir ein feld, was relativ weit unten am
ende der cfg kommt, und lasse einen placeboinhalt automatisch in den
datensatz einfügen (ohne letzteres geht es NICHT!)
und voila.
was leider unschön ist, ich verschwende eine wertvolle zeile in einer
frm-abteilung (man hat jeweils nur 14 zeilen!) und man hat "stuss" in
der datenbank, der irgendwannmal gelöscht werden sollte.... ;-(

trotzdem: der (meine) workaround funktioniert nach den testen tests
;-)

prima, ich danke.
weil: nichts ist schlimmer, als leere felder in der datenbank zu
haben! sie können marc-exporte zum "krachen" bringen (mein
"lieblingsthema")....

viele dankbare grüße
ihr klaus lehmann

PS: ich bin mir nicht sicher, daß diese nachfolgende schweibweise OK
ist:
#77.1 "Datentr.Typ"|Vmtype
     1x LEER hier.

muss es evtl so heissen:
#77.1"Datentr.Typ"|Vmtype
    KEIN LEER hier....

???

danke für Ihre Nachricht.
Am Dienstag, 16. Oktober 2018 um 09:09 schrieben Sie.
Ihre Nachricht finden Sie am Ende dieser eMail.

> Kollege Lehmann:
 >> 
 >> PS: leider ungeklärt:
 >> sind in der frm-datei solche konstruktionen zu finden, wie diese:
 >> (aus der cat.frm)
 >> [Buch, Teil 2]
 >> #73.1 "erweit. ErschAngabe."
 >> #0c.1 "Inhaltstyp"|Vctype
 >> #77.1 "Datentr.Typ"|Vmtype
 >> 
 >> ist an der 5.stell EIN leer oder KEIN leer, dann werden LEERE felder wie
 >> #73.1
 >> #0c.1
 >> #77.1
 >> links oben in a99.exe erzeugt. sie enthalten KEIN leer.
 >> das ganze passiert NUR, wenn auf dem Button "Neusatz(F9)" klick.

> Dazu ein Zwischenbericht:
> Das passiert NUR, wenn zum Zeitpunkt der leeren Eingabe eines dieser Felder im
> entstehenden Datensatz noch kein Feld vorhanden ist, das unterhalb #77.1 in
> der CFG-Reihenfolge stünde. Der tieferen Ursache bleibt weiter nachzuspüren,
> deshalb erstmal nur ein AbhilfeTip:
> Oberhalb von #73.1 ein Feld einsetzen, z.B. #87 oder #85 oder beide, das in
> der CFG-Reihenfolge unter #77 steht.
> Oder: #73.1 usw. in der CFG weiter nach oben rücken, es darf ruhig über der #20
> sein. Sieht dann zwar komisch aus, tut aber der Funktionalität keinen
> Abbruch, und Reorganisation ist nicht erforderlich. 

> NACH einer noch ausstehenden definitiven Lösung KÖNNTE man eine Reorganisation
> ("Datenbank ganz neu aufbuen") machen, muß man aber auch nicht! Es würde genügen,
> in der CFG die alte Reihenfolge wiederherzustellen.

> Für Verblüffte: Die im Programm sichtbare Reihenfolge ist immer diejenige,
> die momentan in der CFG eingestellt ist, egal in welcher Reihenfolge die
> Felder physisch in der Datenbank (.ald-Datei) vorliegen. Anders gesagt:
> Es ist entgegen der Intuition NICHT so, daß die Felder automatisch alphanumerisch
> sortiert würden, sondern sie werden im Arbeitsspeicher beim Einlesen oder Eingeben
> in der Reihenfolge der CFG sortiert und dann auch so gespeichert. Bei erneutem
> Einlesen nach Änderung der CFG und Neustart des Programms wird ein Satz dann eben
> in der geänderten Reihenfolge gezeigt und im Falle daß man speichert, auch so gespeichert.

> B.E.

>  
> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> https://bibservices.biblio.etc.tu-bs.de/mailman/listinfo/allegro

> Um sich von dieser Liste abzumelden, klicken Sie hier:
> mailto:allegro-request at biblio.tu-bs.de?subject=unsubscribe

> To unsubscribe from this list, click here:
> mailto:allegro-request at biblio.tu-bs.de?subject=unsubscribe

-- 
Mit freundlichen Grüßen,
Ihr Klaus Lehmann
http://allegronet.de * eMail: allegronet at t-online.de * phone: 03528-452 807(fax 809) * mobil: 0171-953 7843
allegronet.de * Klaus Lehmann * D-01454 Radeberg * Bahnhofstr. 1
zuständiges Finanzamt: FA Hoyerswerda; zuständige Kammer: IHK Dresden;
zuständige Aufsichtsbehörde: Gewerbeamt Radeberg; USt-IdNr: DE247550760
* Software für zufriedene Bibliothekare: 1000x bewaehrt und ergiebig
* Bereits 4x allegro-utf8. Buchen Sie die allegro-Roadshow. Yes we can!
* Internetkataloge & WebHosting für Allegro-C & Web 2.0 mit VuFind
* 2011-12:  Sponsor: Peter-Sodann-Bibliothek+IFLA:allegro-utf8
* 2013-14: Bolero 64bit.+allegro-zdb: endlich. + eBooks
* 2015-16: allegro-vufind.+ allegro-imd.Die weltgrößte(?) Filmdatenbank
* 2017-18: Exporte. Marc und Co.  Marc ist sehr different
Lesen Sie auf http://portal.allegronet.de/allegrowerkstatt/allegro-windows die
Wahrheit zur Zukunft von allegro-C. Bilden Sie sich Ihre eigene Meinung! Lesen Sie!

Am Dienstag, 16. Oktober 2018 um 09:09 schrieben Sie:
> Kollege Lehmann:
 >> 
 >> PS: leider ungeklärt:
 >> sind in der frm-datei solche konstruktionen zu finden, wie diese:
 >> (aus der cat.frm)
 >> [Buch, Teil 2]
 >> #73.1 "erweit. ErschAngabe."
 >> #0c.1 "Inhaltstyp"|Vctype
 >> #77.1 "Datentr.Typ"|Vmtype
 >> 
 >> ist an der 5.stell EIN leer oder KEIN leer, dann werden LEERE felder wie
 >> #73.1
 >> #0c.1
 >> #77.1
 >> links oben in a99.exe erzeugt. sie enthalten KEIN leer.
 >> das ganze passiert NUR, wenn auf dem Button "Neusatz(F9)" klick.

> Dazu ein Zwischenbericht:
> Das passiert NUR, wenn zum Zeitpunkt der leeren Eingabe eines dieser Felder im
> entstehenden Datensatz noch kein Feld vorhanden ist, das unterhalb #77.1 in
> der CFG-Reihenfolge stünde. Der tieferen Ursache bleibt weiter nachzuspüren,
> deshalb erstmal nur ein AbhilfeTip:
> Oberhalb von #73.1 ein Feld einsetzen, z.B. #87 oder #85 oder beide, das in
> der CFG-Reihenfolge unter #77 steht.
> Oder: #73.1 usw. in der CFG weiter nach oben rücken, es darf ruhig über der #20
> sein. Sieht dann zwar komisch aus, tut aber der Funktionalität keinen
> Abbruch, und Reorganisation ist nicht erforderlich. 

> NACH einer noch ausstehenden definitiven Lösung KÖNNTE man eine Reorganisation
> ("Datenbank ganz neu aufbuen") machen, muß man aber auch nicht! Es würde genügen,
> in der CFG die alte Reihenfolge wiederherzustellen.

> Für Verblüffte: Die im Programm sichtbare Reihenfolge ist immer diejenige,
> die momentan in der CFG eingestellt ist, egal in welcher Reihenfolge die
> Felder physisch in der Datenbank (.ald-Datei) vorliegen. Anders gesagt:
> Es ist entgegen der Intuition NICHT so, daß die Felder automatisch alphanumerisch
> sortiert würden, sondern sie werden im Arbeitsspeicher beim Einlesen oder Eingeben
> in der Reihenfolge der CFG sortiert und dann auch so gespeichert. Bei erneutem
> Einlesen nach Änderung der CFG und Neustart des Programms wird ein Satz dann eben
> in der geänderten Reihenfolge gezeigt und im Falle daß man speichert, auch so gespeichert.

> B.E.

>  
> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> https://bibservices.biblio.etc.tu-bs.de/mailman/listinfo/allegro

> Um sich von dieser Liste abzumelden, klicken Sie hier:
> mailto:allegro-request at biblio.tu-bs.de?subject=unsubscribe

> To unsubscribe from this list, click here:
> mailto:allegro-request at biblio.tu-bs.de?subject=unsubscribe