[Allegro] Vb.300: a99 Erscheinungsbild / Hilfetexte und JanaS / Neues FLEX-UPro sepa.inc

[Bernhard Eversberg]

Verlautbarung 300 zur allegro-Entwicklung                    2018-09-15
-----------------------------------------

I.   V38.3 ist da
II.  a99-Escheinungsbild geringfügig verbessert
III. Neues FLEX-Unterprogramm "sepa"
ANHANG  (Nur für die Akten)

I. V38.3 ist da    [Download  inst-all.exe  von http://www.allegro-b.de]
===============    [alternativ auch als Dateipaket  inst-all.zip]

An den eigentlichen Programmen wurde funktional nichts geändert!
In den letzten Jahren haben sich die Innereien der Programme so
stabilisiert, daß man kaum noch von Abstürzen oder merkwürdigen 
Verhaltensweisen gehört hat - und wenn, dann lag's nicht an den 
.exe-Programmen. Eingriffe in diese C-Programme sind daher schon
seit V37.3 nicht mehr nötig gewesen. Bedarfe für Änderungen entstehen 
deshalb auch fast nur noch in den FLEX-Skripten, nicht mehr in der FLEX-
Sprache selbst. Diese ist stabil und, wie es scheint, für alle noch
anfallenden Wünsche gut gerüstet. (Einzig am äußeren Erscheinungsbild
des Hauptprogramms a99.exe gab es geringfügige Korrekturen, s.II.)
Das alles betrifft sowohl die Windows-Plattform mit a99 / a99a / a9910,
wie auch die Linux-Programme, und da vor allem acon: Auch dieses
Programm, das Kernstück der Web-Oberflächen, hatte keine Änderungen
nötig, sondern die weiteren Verbesserungen z.B. an a35 erforderten
nur Arbeiten an den FLEX-Skripten, also den .job-Dateien. Diese
sind enthalten in dem Paket a35.zip, für Linux a35.gz:
   http://www.allegro-b.de/download

  Wer jetzt also der Nummer 300 entgegengefiebert hat, in der Erwartung
  umwälzender Neuerungen nebst allerlei Pomp und Gepränge, der sieht 
  sich nun ernüchtert. Im ANHANG steht, warum sowieso Abstand genommen
  wird von Feierlichkeiten aus Anlaß der Nummer 300 ...

Der Anhang tut aber nicht wirklich was zur Sache!
Sondern in der Sache geht es nur um folgende zwei Punkte:

II. a99 : Erscheinungsbild geringfügig verbessert
-------------------------------------------------
Das Erscheinungsbild von a99 wird von ÄsthetInnen gern bekrittelt,
weil es "unordentlich" wirke. Das kommt daher, daß man das
Fenster sowohl in seiner Größe als auch in Höhe und Breite frei
verändern kann. Bei einer Größenänderung verändern aber alle Elemente 
proportional ihre Größe, auch die Buttons! Genau das ist bei "echten", 
also ästhetischen, Windows-Programmen nicht so. Änderungen der Größe 
können jedoch nicht völlig kontinuierlich erfolgen, sondern nur 
schrittweise, Pixel für Pixel, und das Pixel hat eine feste,
unteilbare Größe. Das hat zur Folge, daß dann die Abstände der Buttons,
und das ist eigentlich das Auffälligste, nicht alle bei jeder 
Einstellung der Größe exakt gleich sein können. Denn die Anzahl Pixel
zwischen den Elementen muß dann immer neu berechnet werden, und das
geht zahlenmäßig selten genau gleichmäßig auf.
Es waren an einigen Stellen dennoch Verbesserungen möglich und
wurden ausgeführt.

Dazu noch ein Hinweis (keine Änderung): 
Im Menü "Datei" gibt es unten den Punkt "Normalposition".
Damit wird das Fenster nach links oben gerückt und auf eine 
bestimmte, nicht besonders große Größe eingestellt. Danach kann man
es mit der Maus in Breite und Höhe wieder beliebig verändern. Die
zuletzt eingestellte Größe bleibt beim Verlassen des Programms
erhalten, bis man sie bei einer späteren Sitzung mal wieder ändert.
Die Einstellung wird in der .ini/.ina-Datei festgehalten, mit der
man a99 gestartet hat. Dies passiert aber nur, wenn in der .ini/.ina
der Wert
  setsize=1
gesetzt ist. (Die kommentierte Datei cat.ini klärt auf über die in
einer .ini/.ina möglichen Setzungen.)

Man mag meinen, die Funktion "Normalposition" gehöre unter "Ansicht",
nicht unter Datei - denn dort sei es doch unintuitiv. Da ist was dran,
aber weil dies sogar von ÄsthetInnen noch nie kritisiert wurde, bleibt
es jetzt dabei. Nur der Wortlaut wurde geändert, der steht aber nicht
im Programm, sondern in der Textdatei uifeger bzw. uifeeng, Zeile 302:
  uifeger: Fenster Normalposition
  uifeeng: Reset window position and size
(Wer will, kann diese Textdateien auch an anderen Stellen ändern.)

Wir halten fest:
Funktionale Änderungen oder Korrekturen sind keine erfolgt. 
Es gab nur ein paar Änderungen an einigen Hilfetexten und FLEXen 
sowie Parameterdateien.
Folgende Dateien sind einen Hinweis wert: (abrufbar mit X gf name)

$a.cfg  : ermoeglicht jetzt #32R fuer die RVK
cat.api : #89O und #89W werden indexiert:  |9OC... bzw. #9W...
d-html.apr  : bisher nicht im GP, geeignet fuer a35, PHPAC u.a. 
marctxt.apr : MARC21-Export für WorldCat, VuFind u.a.

pkc.flx    : NEU : Primary Key Check (s. Vb299)
numcon.inc : Zahlenkonvertierungen (Nutzung in umrech.flx)
dispex.flx : Visueller Test von Exportparametern im Anzeigefeld:
               Verbesserte Anzeige der Ergebnisse
rdl.flx    : Duplikate und Lücken in Registern finden:
               mehrere kleinere Korrekturen
dnb.flx + srugbv.flx : DNB-direkt und GBV-direkt aktualisiert

Die neuen Funktionen der FLEXe sind eingearbeitet in quick.vw (= die
mit Alt+4 erscheinende Liste) und flex.vw (die alphabetische Liste
des FLEX-Funktionsumfangs: mit  v flex  aufzurufen)

ACHTUNG:
Verbessert sind ca. 30 Hilfetexte, in denen dysfunktionale Links 
vorkamen. Darin war jeweils ein falscher Aufruf des JanaS-Browsers,
was zur Folge hatte, daß ein leeres Browserfenster erschien ...
Hintergrund: Einige wichtige HTML-Dateien liegen im Unterordner html
innerhalb des ProgDir. Um so eine Datei anzeigen zu lassen, gibt es
den FLEX  gj.flx. Wenn z.B. die Datei  expar.htm  angezeigt werden
soll, dann lautet der Befehl:  X gj expar.htm, und nicht, wie es
vorher in den Dateien stand,   x janas expar.htm.
Hinter  x janas ...  muß eine vollständige URL folgen.


II. Neues FLEX-Unterprogramm "sepa"
-----------------------------------
Es stellte sich letztens bei einem Anwender folgende Aufgabe:
Man wollte per FLEX alle Felder des Datensatzes hintereinander 
abarbeiten, und zwar so, daß man die Feldnummer und den Inhalt als 
zwei Variablen dann separat handhaben könnte.
Das Problem ist: Wie trennt man beides, wenn die Feldnummer nicht
immer gleich lang ist:
   #nn ..., #nn2..., #nn.1 ..., #nn.10 ... usw.
Besonders die HFM-Felder #nn.1 usw. sind dabei ein Problem, und daß
die "normalen" Mehrfachfelder, z.B. #402, hinter der Feldnummer kein
Spatium haben!
Dazu wurde ein Unterprogramm sepa.inc geschrieben, das man 
einbinden kann mit "include sepa.inc", und zwar sowohl in FLEXe
für a99 wie auch in .job-Dateien für acon. Und es klappt für
jede CFG, auch für 3- oder 4-stellige, z.B. MARC oder Pica.
Das UP geht so, daß man zuerst einen komplettes Datenfeld in die iV
bringt, z.B. in einer Schleife mit  var k1  und  var k2, und dann
schreibt:  perform sepa. Damit man jeweils die Variablen $tag und $cont.
D.h. aus  #20 Titel  wird  $tag = "#20"  und  $cont = "Titel" 
Damit kann man machen, was man will. 

Die Datei "sepa.inc" liegt im FLEX-Ordner und kann auch
downgeloadet werden mit  X gf sepa.inc

Hier ein Kurzbeispiel, wie man es anwendet:

------------------

// erstes Feld
var k1

:loop
// UPro :sepa liefert iV-Inhalt in 2 Var.: $tag und $cont
perf sepa
//  Jetzt mit $tag und $cont machen, was immer man braucht!
//  Beispiel: beide im Anzeigefeld zeigen
var $tag " = " $cont n
ansi
sho +IV
// nächstes Feld
var k2
if not "" jump loop

include sepa.inc

-------------------

Wenn wir diesen Text sepa.flx nennen, dann wird a99 bei Eingabe von
X sepa
den Datensatz zeilenweise anzeigen in der Form
Feldnummer = Feldinhalt
und zwar erscheinen diese Zeilen unter dem angezeigten Datensatz, das
bewirkt der Befehl  show +IV.

-----------------------------------------------------------------------

ANHANG  [Nur für die Akten, tut nicht wirklich was zur Sache!]
------
Nicht nur Bücher, auch und gerade fortlaufende Sammelwerke haben
ihre Schicksale.
Diese Ausgabe wäre in Wahrheit schon die 313, hätten wir auf streng
fortlaufende Numerierung geachtet. Die wahre 300, das ist schon die
Nr. 287 gewesen. Dieser Fakt ist aber zu dem Zeitpunkt, am 24.7.2017,
keinem aufgefallen.
Es gab zwar in der Numerierung keine Lücken, aber 13 zusätzliche 
Nummern, Sonderhefte sozusagen, und zwar diese:

vb74a    05.08.1996 
vb74b    12.08.1996 
vb78a    07.10.1996 
vb93a    04.06.1997 
vb93b    05.06.1997 
vb97a    18.09.1997 
vb116a   18.08.1999 
vb123a   15.11.1999 
vb149a   03.09.2010 
vb149b   03.09.2010 
vb149c   03.09.2010 
vb263a   02.09.2014 
vb265a   03.12.2014 

Ein anderer, von der Sache her wichtigerer Grund für die Geringachtung
der Nummer 300 ist, daß Programmentwickler nicht dezimal denken,
sondern seit Leibniz "dual", im Zweiersystem. Andere Bezeichnungen 
dafür sind "binär", "dyadisch" und (nicht wirklich synonym) "digital"
(denn engl. "digit" heißt "Ziffer".)
Das eigentliche duale Zahlensystem kommt mit den Ziffern 0 und 1 aus,
und auf unterster technischer Ebene sind ALLE digitalen Daten so
codiert. Die einzelne duale Ziffer wird dabei auch "Bit" genannt.
Aus praktischen Gründen faßt man je 8 Bit zu einem Byte zusammen.
Weil 2 hoch 8 = 256 ist, kann ein Byte genau 256 verschiedene Werte
darstellen: z.B. die Dezimalzahlen von 0 bis 255. Daher ist 256 eine 
SEHR wichtige Zahl. 256 ist 16 mal 16, und 16 ist im 16er-System die
Zahl "10", daher ist 256 die Zahl 100 im 16er-System - genau dies
bedeutet auch das Wort "Hexadezimalsystem".
Statt im 10er- oder Dezimalsystem kann man auch im Hexadezimalsystem
rechnen, also auf der Basis 16 statt 10. Das ist praktischer als mit
lauter Nullen und Einsen. Weil wir historisch nur die 10 Ziffern von 0
bis 9 haben, braucht man für hexadezimale Zahlen noch 6 weitere
Ziffern. Statt sich neue Symbole auszudenken, nimmt man dafür die
Buchstaben A bis F, d.h. die Grundzahlen sind
  0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  10... 
Die einziffrige Hexa-Zahl A steht also für dez. 10 usw., F für 15.
Der dezimalen 300 entspricht die hexadezimale 12C. Und da
haben Sie es: sieht das aus wie ein Grund zum Feiern? 
(Auszusprechen wäre das nicht als "zwölf C", sondern: "hundert-C-und
zwanzig", und "zwanzig" in Hexa-Deutsch bedeutet 32 = 2x16!
Und obendrein: die Hexa-Zahl 300, die entspricht der dezimalen 768  
(= 3x256). Davon haben wir jetzt noch nicht mal die Hälfte ...
Wer nachrechnen will, oder andere Beispiele ausrechnen, kann dazu 
den FLEX  umrech.flx  nutzen: einfach mal  X umrech  eingeben und
dann die Funktion  DEZ -> HEX  wählen!

Jetzt aber zurück zu den Verlautbarungen:
Die ersten 10 Nummern erschienen vom 28.4. bis 14.6.1995, also vor ca.
23 Jahren. 23 ist Hex 17 - nicht nur krumm, sondern auch noch prim.

Und um das Maß (oder die?) wirklich übervoll zu machen:
Noch immer hat dieses fortlaufende Sammelwerk nicht Eingang in die
ZDB gefunden, auch eine ISSN wurde ihm nicht zugeteilt. (Dagegen
stehen welche drin, die schon nach der Nummer 1 ihr Erscheinen 
eingestellt haben.)
Die "allegro news" dagegen hatten es geschafft. Sogar die Titeländerung
(von "allegro-news" zu "allegro news" wurde korrekt registriert.)
ZDB-Id Online: 2042521-1, OCLC: 405845628
Druckausgabe:  25496-4.,  OCLC: 85144856
Von 1990 bis 2002 erschienen 60 Nummern und wurden als Papierausgabe
jeweils an alle registrierten Anwender versandt.
Die ZDB listet um die 50 Bestandsangaben; die UB Braunschweig ist da
zwar nicht aufgeführt, aber gleichwohl *hat* sie das Werk, und zwar 
nicht nur das gedruckte, sondern sie hostet auch die Online-Ausgabe:
  http://www.allegro-c.de/news/
Die älteren Ausgaben wurden dafür alle digitalisiert, aber nicht als
PDF mit gescannten Seiten, sondern (geeignet für Cut&Paste und zum 
Suchen) in HTML, also Text.

Nebenbei: Die "Verlautbarungen" hängen nicht qua Titeländerung oder
Abspaltung mit den "news" zusammen: Beide erschienen von 1995 bis 2002 
parallel, dann wurden die "news" mit Nr. 60 eingestellt. Zu dem 
Zeitpunkt war es längst viel effizienter, Neuer- und Veränderungen 
zeitnah im Mailforum zu verbreiten statt zusammengefaßt in aufwendig 
produzierter und postalisch versandter Papierform.

Wo aber findet man ältere Nummern der Vb's?
Alle ab 124 sind mit im GP, und als Zugabe die 112, weil darin erstmals
das Programm a99 vorgestellt wurde. Die Übersicht kriegt man, wenn man
Alt+4 gibt und dann die Zeile mit "VERLAUTBARUNGEN auswählt. Dann kommt
eine Viewliste. Balken auf die gewünschte Nummer und Enter, schon hat
man den Text vor sich. Oder noch schneller:  v vb eingeben, dann
hat man sofort die ViewListe.

Und die Nummern 1-123? Die fände man, wollte man tatsächlich eine
sehen, nur zum Teil über die Suchfunktion auf der allegro-Homepage, 
weil sie zwar alle in konsistenter Form im Mailforum erschienen sind, 
aber Google hat sie nicht geeignet indexiert. Warum? - Keine Ahnung.
Doch sie liegen alle noch als Textdateien vor. Wir haben deswegen, zur
Feier des Tages, nunja, alle Nummern von 1-123 verpackt in eine Datei
vb1-123.zip, abzuholen hier:

  http://www.allegro-b.de/download/doku/vb1-123.zip

Beim Einpacken wurde mit Mißmut bemerkt, daß es DOCH eine Lücke
gegeben hatte: Es war keine Nummer 19 erschienen. Allerdings
kam zu der Nr. 18 am selben Tage eine ergänzende Mitteilung.
Die wurde jetzt umgetauft in Vb19 und mit eingepackt, und so 
stimmt's nun. Die 19 ist im übrigen dann die einzige, die nicht
vom selben Verfasser stammt wie die anderen, sondern von seinem
Kollegen Matthias Evers. Tusch!

------------------------------------------------------------------
Marginalie (Randnotiz)
"Arbeit dehnt sich aus, bis die Zeit verstrichen ist, die dafür
vorgesehen war." schrieb einmal, frei übersetzt, der britische
Ökonom Cyril N. Parkinson. Bekannt wurde der Satz unter der
Bezeichnung "Parkinsonsches Gesetz".
Der Mann hat noch andere "Gesetze" formuliert, darunter dieses:
"Wenn eine Institution anfängt, ihre Geschichte zu schreiben,
dann ist das der Anfang von ihrem Ende."
Das ist ein Grund, warum hier nur ungern historisiert wurde.
Allerdings wurde dem System "allegro" schon mal von anderer Seite
sein "End of life" attestiert. Stark übertrieben.