1. I have marked all the following lines with a 1. to signify that they are part of the same bug. I don't know how this wiki syntax stuff works when i need to make line breaks.
1. It seems that the requires option used in the template files doesn't work as expected. In a template file i have the following:
1. <macro name=“ref_behandling.klargoering” requires=“”/>
1. <macro name=“de_5_trin” requires=“ref_behandling.klargoering”/>
1. <macro name=“ref_behandling.kirurgisk_procedure” requires=“ref_behandling.klargoering,de_5_trin”/>
1. The header names of the referred macro files are similar til these (i copied them directly to avoid spelling errors). The behavior is as follows: The kirurgisk_procedure is locked until de_5_trin has been filled in. The de_5_trin macro is never locked, not even if the ref_behandling.klargoering has not been filled in. IMPORTANT!!!!!!!! This bug is tied to the fact that “requires” parses for non-characters when deciding when one entry ends and another begins. So if the macro name has, for instance, '.' or '-' in them, they won't work.
If an altitem in an altcombobox can't be found (for instance when innerwidget attribute is misspelled), the client seems to crash right after aknowledging that it can't find it.
Not a bug as such, but when a macro is opened up in the client and you want to scroll down to it using the mouse wheel, you more often than not end up changing several of the combo boxes on the way down. Changing combo boxes using the mouse wheel should be disabled overall.
Hvis man lige har valgt noget i en combobox, har jeg for vane lige at klikke et “tomt” sted bagefter, så combobox'en bliver unselected for at undgå at man kommer til at trykke pil og skifter den uden man ligger mærke til det. Når man gør det i pracro klienten ender jeg altid med at ramme en af macro linierne hvorefter save, close, cancel dialogen dukker op. Det er meget generende. Åbn/luk macroer bør begrænses til kun at foregå med åbn/luk knappen til venstre for titlerne.
Vælges “cancel” i dialog boksen der dukker op når man lukker en ændret macro, så har man pludselig to macroer åbne på samme tid.
Når en resumé tekst er for stor i en eller anden grad, så skriver clienten kun 2-3 af linierne når en macro lukkes. Resten forsvinder nedadtil eller ud i højre side udenfor vinduets område.
Det bør være muligt, via lua, at lave et script der spørger om en checkbox er true eller false i stedet for at man, som nu, skal bruge getValue. Det medfører at man skal skrive checkboxens truevalue mindst to steder i dokumentet og de _skal_ stemme overens. Ændrer man derfor det ene sted kan det skabe stor forvirring. Ofte vil man endda bruge det mere end 2 steder når man også bruger det i if sætninger i resumeet.
Det er ikke muligt at bruge < og > på fornuftig vis i macroerne lige pt. De skal escapes dobbelt, men selv da giver de problemer når så resuméet bliver vist for her er de ikke længere escapet nok. Et work-around er pt. at escape dem 3 gange, men det virker lidt tåbeligt.
Vinduernes placering huskes ikke altid til næste gang Pracro åbnes.
“Supplerende” lineedit i konklusionen i ref_forunders kommer ikke altid med i resumeet. Det lader til at være lidt tilfældigt om den bliver gemt eller ej så det må antages at være et problem i kommunikationskoden mellem server og klient. Det kan dog ikke udelukkes at det skyldes en fejl i makrokoden.
Når lægen/optikeren bruger ref_kir makroerne, så lukker de ofte Pracro midt i en undersøgelse fordi de skal vente på at patientens bliver dilleteret (det tager ca. 30 min.). I den sammenhæng tager de en ny patient ind midtvejs og vender senere tilbage til den dilleterede patient. Det bevirker at sammenhængen i teksten der indsættes af Pracro makroerne bliver delt i 2 og at rækkefølgen af dataene der er indsat i Pc-Praxis journalen ikke længere stemmer overens med Pracro templatens rækkefølge. Dette er et problem når patienten sendes til OP, hvor lægerne skal kende visse værdier for at kunne udføre en operation. For at finde disse værdier skal de nu rode rundt i journalen, med risiko for at de værdier de finder enten er blevet overskrevet med nye værdier længere nede, eller også er uddaterede. Det er IKKE optimalt på nogen måde. Det skal diskuteres igennem med Toke og Co. (Kristina, Henrik, Nicolai og Bent).
I ref_kir forunders template under konklusion, klager Kristina over at hun altid skal vælge øje, også selvom hun vælger “andet” under operationstype. Det bevirker, siger hun, at der opstår mulighed for fejl, da de nogen gange skriver “skal konsultere med jesper før der vælges øje”. Når de skriver dette er de stadig tvunget til at vælge øje, så der fremgår altså en øje i journalen, selvom de endnu ikke har lagt sig fast på det. Når de så senere har konsulteret Jesper, så udfylder de øjet korrekt. Når operation skal foretages, vil der derfor være angivelse af øje to steder. Kigges der ikke det korrekte sted, kan det i yderste instans bevirke at patienten bliver opereret forkert. DET MÅ IKKE SKE!!!!!!!!!! Foreslag til ændring er at øje-comboen simpelthen bliver deaktiveret hvis der vælges andet.