Re: [Allegro] im register: das sortieren von signaturen mit zahlen ohne füllziffern -wie?- [ÜBERSICHT]

Klaus Lehmann lehmann_klaus at t-online.de
Mi Nov 2 00:38:55 CET 2005


On Tue, 01 Nov 2005 12:00:04 +0200, Heinrich Allers wrote:


guten abend herr allers (und andere beteiligte)

ich bin überwältigt: so viele antworten: auf mein triviales(?) problem:
danke!


'versuch mal, alle antworten an die kollegen (fr. lass, h. berger, fr.
hübner, h. kretschmer, h. eger und h. thamm [DANKE allen!!] in dieser
mail zusammen zufassen, damit die liste nicht mit meinen antworten
zugemailt wird.



kl>> der computer sortiert nach ascii-liste, klar. wie denn auch sonst.
kl>> schöner wäre ff sortierung:
kl>> Zn 2
kl>> Zn 3
kl>> Zn 10
kl>> Zn 100

kl>Das ist nur eine von mehreren Arten, "intellektuell" zu sortieren:
eine 
kl>freilich recht eigenwillige, nämlich die nach Stellenzahl der
Notation: 
kl>2 sortiert vor 100 - soll dann z.B. auch 99 vor 111 sortieren?

ja, warum nicht? 99 (=099) ist doch kleiner 100 (=100). 
es soll eine numerische sortierung sein.



 
kl>> es wurde behauptet, oder sich erinnert, daß frühere
kl>> braunschweiger-api-versionen genau dieses gekonnt hätten. stimmt
das?
kl>
kl>Ich erinnere mich nicht daran.

kl>> das kann nicht trivial sein....
kl>Nee, bestimmt nicht.
 
kl>> meine lösung wäre:
kl>> die kollegen müsste die signi's so schreiben:
kl>> Zn 001
kl>> Zn 002
kl>> Zn 003
kl>> Zn 100


kl>
kl>Geht schlecht, wenn die Signatur Zn 1 usw. heißt.
ja, deshalb ja meine idee, sollen's die kollegen doch gleich
computerlesbar eingeben, um den problemen zu entgehen. h. berger
empfahl als hilfe, tontäfelchen zu nehmen ;-))))




kl>Eine tolle Möglichkeit zur Manipulation der Sortierung im Register 
kl>bieten die i-Umschlüsselungen (siehe Beginn von 10.2.4.5 Indexcodes
des 
kl>Systemhandbuches). 
'denke nicht, daß man damit hier eingreifen kann.
viele der o.g. kollegen nannten den r-befehl.
und siehe da, wenn man die cat.api sich (endlich) mal näher anschaut,
dann steht doch hier die lösung.
(?wo hatte ich meinen kopf?).






    Die Eintraege fuer die Signatur muessen lokal angepasst werden:
#-O                                      
#t{ "|8" }
#-8    Umcodierung der Benutzereingabe fuer Reg.8
#u1 >O   UPro #(O
#+#

#(O    Signaturaufbereitung. Form:  gruppe[ .-/]zahl[(, ]anhang
       wenn andere Struktur, dann dieses Unterprogramm aendern
  !cc e"" E"[ .-/]"
  !cc e"" b"[ .-/]" e"[(, ]" r5
  !cc e"" b"[ .-/]" b"[(, ]" r3 p" "
!cc B"'" e"[0123456789]" F" " dsg asg     bis zur ersten Ziffer
!cc B"'" e"" x"*1" e"." f"-0" b0 r5 Asg           Zahl, 5stellig, ohne
fuehrd. 0
!cc B"'" e"" b"[0123456789]" f"01234567890.," Asg    Rest
!usg f" "
!usg dsg e0
#)O




mir hat nur früher bereits die darstellung der signaturen nicht
gefallen, so daß ich diesen abschnitt #-O einfach umschrieb. die großen
lücken waren mir damals ein dorn im auge.
jetzt ist klar, was die lücken sollen. es sind die "auffüller"!!!

#-O                                        
!u1 e"" y0 p"|8"
#+#




ich fasse mal zusammen:
es gibt mindestens drei lösungen:



1. 
#-O                                      
#t{ "|8" }
#-8    Umcodierung der Benutzereingabe fuer Reg.8
#u1 >O   UPro #(O
#+#
#(O    Signaturaufbereitung. Form:  gruppe[ .-/]zahl[(, ]anhang
       wenn andere Struktur, dann dieses Unterprogramm aendern
  !cc e"" E"[ .-/]"
  !cc e"" b"[ .-/]" e"[(, ]" r5
  !cc e"" b"[ .-/]" b"[(, ]" r3 p" "
!cc B"'" e"[0123456789]" F" " dsg asg     bis zur ersten Ziffer
!cc B"'" e"" x"*1" e"." f"-0" b0 r5 Asg           Zahl, 5stellig, ohne
fuehrd. 0
!cc B"'" e"" b"[0123456789]" f"01234567890.," Asg    Rest
!usg f" "
!usg dsg e0
#)O





2. 
#-O                                      
#t{ "|8" }
#-8    Umcodierung der Benutzereingabe fuer Reg.8
#u1 >O   UPro #(O
#+#
#(O    Signaturaufbereitung. Form:  gruppe[ .-/]zahl[(, ]anhang
       wenn andere Struktur, dann dieses Unterprogramm aendern
!cc e"" E"[ .-/]"
!cc e"" b"[ .-/]" e"[(, ]" r5
!cc e"" b"[ .-/]" b"[(, ]" r3 p" "
  !cc B"'" e"[0123456789]" F" " dsg asg     bis zur ersten Ziffer
  !cc B"'" e"" x"*1" e"." f"-0" b0 r5 Asg           Zahl, 5stellig,
ohne fuehrd. 0
  !cc B"'" e"" b"[0123456789]" f"01234567890.," Asg    Rest
!usg f" "
!usg dsg e0
#)O




3. 
#-O                                        
!u1 e"" y0 p"|8"
#+#




4. der lass'sche ansatz ist auch nicht ohne:
#39E     Signaturen im 6. Index
#u1 +#39G i4,C e0
#u1 y0 e" " p"|6" 0 #zz 0
#u1 b" " e" " F"LS" r5
!u1 b" " b" " e"(" p" "
!u1 b"(" e")" p"(" P")"
#+#


#39G     Signaturen im 6. Index, hier Gruppe C
#u1 e" " p"|6" 0 #zz 0
#u1 b" " e" " F"LS" r6
!u1 b" " b" " e"(" p" "
!u1 b"(" e")" p"(" P")"
#+#
das hat zu folge, daß die sichtbare reihenfolge excellent aussieht.
aber: ganz gravierende (für mich!) nachteile: ich muss eine bestimmte
menge an führungsnullen miteingeben. für kollegen mag das gehen, die
kann man trainieren, aber nicht selbstständige leser (hups: sind
kollegen nicht selbstständig? ;-)





jede dieser lösungen hat seine vor- und nachteile.



übersicht:
==========
1. ist die aktuelle. aus der langen cat.api vom 1. sept.2005
2. ist eine ältere lösung aus BS, von wann?
3. setzt lösungen 1+2 ausser kraft, und bildet die signatur einfach im
reg9 ab.
4. lass'sche spezialität aus BS: schön/elegant, aber mit nullen
(einzugeben)!



vorteile:
=========
1. die signaturen mit zahlenwerten werden zwar etwas merkwürdig
dargestellt, aber korrekt (numerisch) sortiert. in kauf zu nehmen sind
große(!) zwischenräume zwischen den signatur-bestandteilen. 
beispiel: Zn   99.   einige (viele) leerzeichen zwischen Zn und 99, das
macht die sache "optisch merkwürdig"
lücken in der nummernvergabe sind zu sehen.

2. habe ich nicht gestestet.
was macht es genau?

3. bildet die signatur genauso ab, wie sie geschrieben wird. es wird
unterschieden zwischen groß und kleinschreibung. das ist nicht
verkehrt! ich habe diese variante bis heute bewusst gewählt, weil man
so die kontrolle über seine vergebenen signaturen bekommt. sprich:
fehler in der schreibung (klein oder gross) sind bewusst zu sehen! 
?nachteil?: man muss auch mit groß bzw kleinsuchen! DAS weicht vom
allegro-standard-eingabe modus für die register suche ab!

4. optisch gefällt mir das am besten. keine leerräume (wie bei 1.)






nachteile:
==========
1. merkwürdige leerräume zwischen den signaturenteilen. 
optisch: nicht "schön"

2. .-.

3. es muss in der original-schreibweise gesucht werden.
wenn man lücken erkennen will, muss man wie berger sagt: tontäfelchen
nehmen (im übertragenen sinn!!!) ;-)

4. ich muss mitdenken, und nullen eingeben. ich will aber nicht
mitdenken, schon gar nicht als leser. meine devise: die indexgestaltung
MUSS selbsterklärend sein. die überschriften haben nur WENIG raum für
erklärende hinweise. die hilfstexte schaut sich sowie NIEMAND an!

ist evtl diese lösung nicht flexibel? muss ich genau bedenken, oder
eingrenzen: 4stellige signi-systeme sind nur möglich? wenn 5stellig,
dann eine neue hopsmarke?
[h. thamm weist auf die wandlung der nutzereingabe hin, hier sei eine
verbesserung möglich, dann würde auch die lass'sche lösung praktikabler
werden. [wie?] ...]
[an h. thamm: wieso reg6? ist dort die signatur? ich denke, sie ist
allgmein bei reg8: aber dafür entdecke ich keine wandlungen der
benutuzereingabe IN der api!?]





mein resümee:
=============
es wird einige (wenige) bibliotheken geben, wo die kollegen MEHR wert
auf die numerische reihenfolge legen. 
das bedeutet: sie können die signaturen kontrollieren: wo ist eine
lücke? o.ä.

es wird mehr bibliotheken geben, die legen wert auf die
kontrollierbarkeit der schreibweise (gross/kleinschreibung). sie werden
inkauf nehmen müssen: die numerischen lücken sind nicht leicht
erkennbar, weil die sortierung etwas "unegal" ist .

ich sehe kein signaturenmodell, welches alle vorteile aufweist. das
scheint mir unmöglich. (oder irre ich mich?)
!?wenn der lass'sche ansatz wirklich flexibel ist, dann wäre er der
idealkandidat!?


dann gibt es noch den aspekt der internetkataloge. herr eger weist auf
mögliche (welche?) stolpersteine hin. 




so, dieses soll genügen. 
bitte korrigieren sie mich, sollte ich was falsch verstanden haben...
das war eine zusammenstellung aller beteiligten emails. vor-und
nachteile wurden aufgezeigt. 
mir scheint, es gibt keine eierlegendewollmilchsaudersignaturen ;-)



viele grüße
ihr klaus lehmann

-- 
Klaus Lehmann
eMail: lehmann_klaus at t-online.de
phone: 03528-452 807; mobil 0171-953 7843
adress: D-01454 Radeberg; Kleinwolmsdorfer Str. 37

*** Ihre langjährige allegroC-Werkstatt: 
Internetkataloge & WebHosting für AllegroC-Kataloge, Datenbank-
bereinigungen, Safer Shells, Fehlerindices, komplette Arbeitsumgebungen, 
Fremddaten: Import/Export; Batchprogrammierung & andere Automatismen.
Admin fuer Netware/Windows/Linux/Samba
*** Our best ideas are born at home (New Freedom Data Center 1995) ***
    one of those new ideas see at http://allegronet.de





Mehr Informationen über die Mailingliste Allegro