Snel data ingeven met een tekstgebied (TextArea)

Gambas2 TextArea Input, leeg (screenshot)

Tekstgebied voor invoer

Als je op een scherm (Form) data laat ingeven moet je altijd een compromis zoeken tussen

  1. efficiëntie van de input
  2. controle van de input

Door punt “controle” zou je geneigd kunnen zijn meer aparte tekstvelden te gaan gebruiken, waarvan je telkens de invoer controleert. Waarbij de gebruiker, om zijn hele invoer te kunnen doen, dan wel telkens van veld moet veranderen (indien: implementeer TAB mogelijkheid!).

Een tekstgebied (TextArea), dat je eventueel “in de hoogte” vormgeeft, laat toe snel opeenvolgende woorden (zinnen) in te geven, hier vooral een reeks onder elkaar dus.

Ik laat de gebruiker achtereenvolgens de invoer doen, en op het moment dat hij het tekstgebied verlaat, doe ik de controle en geef feedback. Daarvoor worden de regels van het tekstgebied gesplitst in “zinnen”, die elk als één invoer beschouwd worden.

Gambas2 TextArea Input End (screenshot)

Na drie lijnen invoer, een enter, en nog een…

PUBLIC SUB doImportClassValues()

  DIM sLine AS String
  DIM hArrStr AS NEW String[]
  hArrStr = Split(txaeClassNames.Text, gb.NewLine) 
  
  setState(cAdd)
  
  FOR EACH sLine IN hArrStr
    doCheckSave(sLine)
  NEXT 
  

Om het toetsenbord niet te moeten verlaten bij het einde van de invoer, tel ik twee achtereenvolgende “volgende regel” (enter/return) als teken om te stoppen: gebruiker heeft een lege regel ingevoerd, en daarna nog één. Dat is het teken voor “klaar”, de verwerking van de invoer wordt gestart.

Om gemakkelijk toegang te geven tot de invoer in het tekstgebied gebruik ik bv een dubbelklik op het tekstgebied.

De teller voor het aantal enters is vooraf hoger gedefinieerd als
PRIVATE $iLastEnter AS integer

De toets voor enter/return wordt zo getest en geteld:

PUBLIC SUB txaeClassNames_KeyPress()
'
  IF Key.Code = Key.Enter OR Key.Code = Key.Return
    INC $iLastEnter 
    IF $iLastEnter = 2
      doCheckSaveValues(txaeClassNames.Text)
      $iLastEnter = 0
    ENDIF 
  ELSE 
    $iLastEnter = 0
  ENDIF 
'
END

Inputbox

Gambas InputBox

Snel data laten ingeven vanuit code

De inputbox komt niet voor in het menu rechtsonder, bij de tabbladen Form of Container, en daardoor zou je deze functie over het hoofd kunnen zien.

Ze is handig om vanuit code snel invoer toe te laten, omdat je het antwoord onmiddellijk als waarde terugkrijgt.

De tekst die weergegeven moet worden als vraag om invoer of als verklaring, wordt als parameter meegegeven.

Op dezelfde manier kan (optioneel) een titel voor het venster gegeven worden.

Ook optioneel is een “standaardwaarde”, wat wil zeggen dat ze vooraf ingevuld wordt;

teruggeefwaarde = InputBox("Geef een getal (in cm) van 1-999 ", "Lengte-invoer", "***")

Er kunnen zowel cijfers als letters ingegeven worden, dus invoer controleren!

De tekst met de vraag binnen het venster, kan opmaak kenmerken meekrijgen:

InputBox("Geef een getal <em>(in cm)</em> <br> <font color='darkgreen'>van 1-999</font>", "Lengte-invoer", "***")

Opgelet; de sterretjes betekenen hier niet ‘onzichtbare ingave’ zoals voor “wachtwoord”.

Het PaxHeaders spook / PaxHeaders Ghosts

PaxHeaders Ghosts (NL: Het PaxHeaders spook …)

Suddenly, the packages that I make with Gambas2 seem to be much bigger than before. If I examine (look into the tar.gz files with Konqueror), they seem to contain the compiled .gambas file, which has landed in the source directory some moment; so I remove that. But also I found some mysterious “PaxHeader” directories. These always end with a 4 digit number, that becomes bigger at every creation. This can be reproduced by making an new project, and create a package from within the Gambas2 IDE. One example of a directory that appears is:

PaxHeaders.5028

This occurs for me on OpenSuse 12.2 Mantis, with Gambas2 (2.24), on openSUSE Linux kernel 3.4.47-2.38-desktop.

On this moment I don’t see anything mentioned on the gambas-user list, I suppose it has nothing to do with gambas itself. One mention I found is on a KDE list.

You can “see” this gosts with Konqueror, but not with Ark of with Dolphin. Maybe Konqueror sees something that is not there? (or the other way around in Ubuntu?)

Might be corrected with an openSUSE update soon…


Het PaxHeaders spook

Op een bepaald moment ontdek ik dat de tar.gz bestanden die gemaakt worden vanuit de Gambas2 IDE veel groter geworden zijn. Met KDE’s bestandsbeheerder zie ik dat er een .gambas inzit, wat staat voor het gecompileerde programma. Dat is in de source directory terechtgekomen, en wordt zo als bestand mee in het pakket opgenomen; ik verwijder het uit de broncodemap.
Ik merkte echter ook dat er in de .tar.gz een aantal eigenaardige directories zitten.
Ze hebben een naam die begint met PaxHeader en eindigen met een 4-cijferig nummer, zoals bv

PaxHeaders.5028

Het komt voor op de huidige OpenSuse 12.2 Mantis, with Gambas2 (2.24), on openSUSE Linux kernel 3.4.47-2.38-desktop.

Je “ziet” het ook alleen met Konqueror, niet met Ark of met Dolphin, wat er misschien op wijst dat Konqueror iets weergeeft dat er helemaal niet is?

Vermoedelijk ligt het anders aan KDE of de onderliggende bibliotheken die gebruikt worden om de bestanden in te pakken.

Ik hou in de gaten of er updates zijn, en wanneer het verholpen is…


update 5/9; dit zou een verklaring kunnen zijn (hoewel omgekeerd tussen konqueror en dolphin): een bug in de bestandsbeheerder die enkel een foute weergave doet; hier vermelding bij Ubuntu, een andere distributie, die ook met KDE werkt:


…show misleading PaxHeader..

Version: (using KDE 4.3.0)
Installed from: Ubuntu Packages

Some tar files created in KDE 4.3 from within Dolphin’s context menu do not
show their contents properly. When clicking on them to show them as a folder,
they have some PaxHeader folders inside and these have the wrong directory
structure. However, when deflating the tar.gz file the resulting directory is
in fact as it should be. Therefore, it is only the Dolhin view mode that is
bugged, not the creation or deflation of the tar.gz files.