scriptotek / bibduck Goto Github PK

Fra Magnus:

Jeg sitter og går gjennom litt ymse bestillinger i Bibsys og bruker LTST og LTSØK ganske mye. Defaulten når man går inn i den er at pekeren står i "Etternavn, fornavn"-feltet. Da er det litt styr å shift-alt-tabbe tilbake til "Ltid" hele tiden. I Bib-skjermen har du på magisk vis fått "Forfatter"-feltet til å lese et dokid. Er det mulig å gjøre det samme så "Etternavn, fornavn" leser ltid til en senere versjon av anda?

som med DOKID

Forslag fra Bente:

Kanskje du kunne fikse det samme når vi registrerer reserverte bøker? For imott var veldig bra i duck-style

Vi sender ikke pensumbøker med kassen internt på ubo.

Vanlig prosedyre er:

• hentb, velge epost og skrive at boka må hentes på det-og-det biblioteket, ikke ditt vanlige bibliotek

Kunne Bibduck gitt advarsel ved pensumbok, og evt. fylt inn meldingen automatisk?

Siden SNetTerm/Bibsys skrur av NumLock, noe som er irriterende, tilbakestiller Bibduck den opprinnelige NumLock-tilstanden når påloggingen er ferdig. Men hvordan? Å endre NumLock-status er ikke noe problem, det kan vi gjøre fra WScript.Shell, men å lese NumLock-statusen derimot (vi vil jo ikke skru på NumLock hvis brukeren faktisk ønsker å ha NumLock av), nei, se det er ikke like enkelt. Men på Windows-plattformen finner man gjerne ting på de mest uventede steder – fra et Word.Application-objektet er det enkelt å lese NumLock-status. Så vi oppretter et midlertidig Word-objekt som vi umiddelbart sletter igjen. Dette burde ikke skape noen problemer, men Reference Manager ser ut til å være basert på at det ikke skal være flere samtidige Word-instanser?

Løsningen må bli å skru av denne funksjonaliteten for de som bruker Reference Manager. Jeg kommer til å lage en innstilling for dette.

Jeg er ikke helt sikker på hvorfor dette skjer, men kan gjette på at det har noe med at BIBDUCK spør etter ressurser som allerede er frigitt.

Funksjonelt sett er det ikke særlig farlig at et program kræsjer når det uansett skal avsluttes, og det skaper ingen problemer for BIBDUCK, men det resulterer i to feilmeldinger som kan gi brukeren en sterk indikasjon på at "noe er galt".

Forslag fra Live

Bakgrunn: Aktive og passive vinduer

Bibduck følger med kun med på aktive vinduer.

• Aktive vinduer kjennetegnes ved at tittelen vises med stående skrift i vinduslisten.
• Passive vinduer vises i kursiv.

Et vindu blir aktivt når man interagerer med det, enten med tastaturet (også strekkodeleser og RFID-plate) eller ved å klikke med muspekeren i selve blåskjermen. Et vindu blir ikke aktivt når man trykker på verktøylinja, tilttellinja, fanelinja eller lignende.

Dette innebærer at Bibduck ikke umiddelbart får med seg om du

• bytter mellom faner ved å trykke på en fane i fanelinja.
• bytter mellom vinduer ved å trykke i vinduet utenfor selve blåskjermen.

Men byttet registreres umiddelbart om du bytter mellom faner der innsettingspunktet er på ulike posisjoner. (Programmeringsgrensesnittet har ikke støtte for faner i det hele tatt, så det sender bare ut et signal om at innsettingspunktet har flyttet, noe Bibduck responderer på.)

Problemet

Hvis de to vinduene/fanene du bytter mellom har ulik RFID-modus (f.eks. ett med REG-skjerm og ett med RET-skjerm), kan RFID-modus bli hengende igjen helt til Bibduck registrerer fane-/vindusbyttet. Siden dette skjer så fort du interagerer med vinduet som beskrevet ovenfor, er dette vanligvis ikke noe problem. Men hvis du bytter vindu/fane (på en slik måte at bytte ikke registreres umiddelbart) og umiddelbart legger en bok på RFID-plata kan det være det.

Løsning?

Den eneste løsningen jeg ser på dette, innenfor de begrensningene som SNetTerm-programmeringsgrensesnittet setter, er kontinuerlig polling av skjermen, men da blir minnelekasjen fort problematisk.

I praksis må vi antakelig leve med dette problemet. Kjenner man til det, er det ikke noe vanskelig å leve med. Og selv brukere som ikke kjenner til det vil nok svært sjelden komme borti problemet i praksis.