Wat prive gezegd wordt in de klasse, blijft in de klasse

Ik weet het al van lang geleden (zie naamgeving over gambas syntax), maar ik heb nu nog eens nagekeken of het in gambas3 ook nog zo gebruikt wordt, en ja.

Naming Conventions

The naming conventions are not required by the compiler. But programs which use the following naming conventions are easier to read by other programmers who want to understand the program.
Variable names

All private variable names of a class start with $

The first letter is lower case and should depend on the type of the variable

Voordeel van het markeren van de private variabelen in de klasse, is dat je gemakkelijk kan zien wat naar buiten gaat (nl alles waar geen $ voorstaat). Handig en belangrijk als je extern waarden toegespeeld krijgt en die moet verwerken in een private var in de klasse:

Private Sub checkGivenMonthYear(Optional iMonthIn As Integer, Optional iYearIn As Integer) As Boolean
'
If (iYearIn)
$iYear = iYearIn

Van buiten de klasse mag je dus geen $var tegenkomen, dan weet je dat er iets fout is. De publieke variabelen hebben dus een gewone naam, van buitenaf zichtbaar, en geen $ teken.

Voorbeeld uit de Gambas 3.18 bronccode, FMain.class:

' Gambas class file
'
Public NoMessage As Integer
'
Private $hProjectTree As CProjectTree
'
Private $sKey As String
Private $bCtrl As Boolean
Private $bInRename As Boolean
'
Private frmWelcome As FWelcome

(dus niet voor een Form)

Het programma dat werd geïmporteerd uit gambas2 naar gambas3 3.14 (op KDE/openSUSE 15.3) crasht of (gedraaid vanuit de IDE) stopt met de melding:

ValueBox.Allowed is not a property

Een zoek op “ValueBox.Allowed” in de broncode van het scherm waarin het gebeurt levert niets op.
Een zoek op “ValueBox.Allowed” in de broncode van het hele project levert ook niets op.

Langzaam begin ik te vermoeden dat de foutmelding te maken heeft met het venster (Form) dat een beetje verder in de code geopend wordt.

In dat scherm worden een aantal waarden geïnitialiseerd, en daarbij worden valueboxen zo behandeld:

vlbxSomeValue.Clear()

Die heb ik er uit gehaald;
(eventueel vervangen door:
vlbxSomeValue.Value = 0?)

Het volgende probleem is:
vlbxAmounthh.Select()

Geval 1: gb.qt4.ext, qb.gui.qt.webkit
Na updates van mijn OpenSUSE (van 42.3 naar 15.1) werken sommige applicaties die met Gambas3 gemaakt zijn, niet meer.

Het gecompileerde programma, met link op de desktop, lijkt te starten, maar sterft dan een stille dood.

Bij het openen van het project in Gambas3:

Sommige componenten worden gemist: gb.qt4.ext

Het probleem is waarschijnlijk dat er Qt4 specifieke componenten zijn gebruikt, en die zijn nu niet meer aanwezig of verkrijgbaar.

Test:
– project openen, ga verder en negeer de waarschuwingen van missende componenten.
– Project eigenschappen: vink gb.qt5 en gb.qt5.ext aan

Of:
– gb.gui.qt (QT4/QT5 switcher component)

Daarna nog:

Cannot load class “Editor”: Unable to load class file

En:
– gb.gui.qt.webkit (QT4/QT5 WebKit switcher component)

Maar dat blijkt niet alles op te lossen… :

Unknown Control: Editor

Gelukkig had ik 1 nog niet ge-update toestel waarop ik de oude versie kon openen.
Inderdaad werd daar een gb.qt4.ext object “editor” gebruikt dat code in kleur weergaf. Bestaat dat niet in qt5?

Ik denk dat ik in de oude opstelling de waarschijnlijke probleemobjecten zoals qt4 Editor er uit moet schrijven en checken of het dan wel werkt…

Daar zag ik dan in de help dat Editor “deprecated” is sinds 3.8 – “use TextEditor control instead”.

Na de vervanging van die control, en het overschakelen op de algemene gb.gui.qt werkte de applicatie terug.

Geval 2: Dial, LCDNumber, TextEdit, ?

Applicatie omgezet (gambas2 code geïmporteerd in gambas3); geeft een foutmelding op Qt4.ext en werkt niet; de forms bestaan uit tekst met accolades in plaats van een echte form. Ik kan dus in gambas3 ook niets “corrigeren” want ik krijg de form niet open.

Ook hier heeft het te maken met gb.qt4.ext; en die zijn op het nieuwe systeem niet meer aanwezig.

Een tweede fout was

CComponent.Load.626
‘UserControl’ class is missing in gb.form component exported classes
[OK]

en

CComponent.Load.626
‘UserControl’ class is missing in gb.db.form component exported classes
[OK]

gb.qt4.ext
Deze bevat:

• Dial
• LCDNumber (vervangen door LCDLabel?)
• TextEdit

Converteren?
Dé vraag is : kan ik met een recente gambas versie, 3.14.3 bv, (en zonder die qt4 spullen in mijn systeem) dat programma repareren?
Of moet ik op het nieuwe systeem iets als libqt4-devel installeren?

Gelukkig heb ik hier nog een Gambas 3.9.2 op opensuse 42.3 die de oude qt bestanden heeft, en waarin ik het oude programma open krijg. Ik moet daar, veronderstel ik, dan de bovenstaande typische qt4.ext objecten gaan zoeken, die in de code vervangen, en dan opnieuw proberen in het nieuwe systeem … Vermoedelijk zal dat gaan werken als ik op het oude systeem in de IDE de qt4.ext kan uitschakelen in de project-eigenschappen.

(gb.qt4 en gb.qt4-ext af, gb.qt5 en gb.qt5-ext aan).

2 in 2020?
Gambas3 natuurlijk, maar ook Gambas2 draait nog steeds op een huidige openSUSE Linux desktop die steeds bijgewerkt werd.
bv: Een OpenSUSE 15.1 heeft nog een Gambas2 versie: 2.24.0-2.1 uit Education/ openSUSE_Leap_42.2 repository (-nu buiten gebruik; daarom “rood” in Yast/Software management).
Daardoor kan je programma’s die nog niet omgezet zijn naar Gambas3 toch blijven gebruiken…

ps: in principe kan je ook je gambas2 project importeren in gambas3, en dan aanpassen waar nodig.

Kan je het ook nog nieuw installeren?

Distributies

• openSUSE Tumbleweed: Gambas v 2.20.2, Repository: Community home:swyear
• openSUSE Leap 15.1 en 15.2 : Gambas v 2.24.0 Repository: KDE:KDE3 Experimenteel
• Er wordt op software.openuse.org nog een community versie vermeld voor Tumbleweed/Factory
  

  URL: https://download.opensuse.org/repositories/home:/swyear/openSUSE_Factory/
  Categorie: YUM

Dus in theorie kan het nog, weliswaar “experimenteel”.

• Je kan proberen alleen de “runtime” te installeren, zodat je bestaande .gambas programma’s nog kan draaien.
• Of waarschijnlijk moeilijker: de hele IDE installaren, zodat je gambas2 programma’s kan wijzigen/nieuw maken.

Maar in de praktijk is het niet zo eenvoudig….
Op een nieuwe installatie van 15.1 draait het (voorlopig) niet bij een gewone install van gambas2 uit de genoemde repo; ik volg mogelijk updates en geef in het 2.x update artikel aan met een (-) dat het nog niet veranderd is (zonder zelf extra dingen bij te installeren of linken).
Continue reading →

(zie ook Gambas3 updates)

Het is een geruststelling voor wie afhankelijk is van Gambas 2 programma’s; zelfs in een recente distributie als openSUSE Leap 24.3, 15.1,.. komen nog altijd (kleine) updates binnen voor Gambas2: (-)* werkt niet?

2021-06-03
OpenSUSE 15.2
gambas2-2.24.0-lp152.61.8
Foutmelding op omniORB 4.1.4-lp152.6.1
requires libomniDynamic…
… Enkel de rest geïnstalleerd.

2021-04-12
OpenSUSE 15.2
– gambas2 en KDE3 update.

2021-03-11
OpenSUSE 15.1 is EOL, dus datzelfde systeem geüpgrade naar OpenSUSE 15.2, en dan ook de KDE3 repo’s aangepast naar 15.2; er staat dan een update klaar naar een lager sub-nummer:
KDE:KDE3 | gambas2 | 2.24.0-lp151.61.8 | 2.24.0-lp152.61.2 | x86_64
Gaat ook samen met KDE3:
KDE:KDE3 | kdebase3 | 3.5.10.1-lp151.359.4 | 3.5.10.1-lp152.359.1 | x86_64

Bij de updates komt er een foutmelding op omniORB;
omniORB | 4.1.4-lp151.5.1 | 4.1.4-lp152.5.1

2021-02-09
(..)

2021-01-22
OpenSUSE 15.1: gambas 2.24.0-lp151.61.5
Foutmelding op:
gambas2-gb-corba-2.24.0-lp151.61.5.x86_64 requires libomniDynamic4.so.1()(64bit), but this requirement cannot be provided
Kan afgevinkt worden, dan installeert de rest wel..
Nadien met zypper up komt de melding:
/sbin/ldconfig: /usr/lib64/libffi.so.4 is not a symbolic link

2021-01-12
OpenSUSE 15.1: gambas 2.24.0-lp151.61.3
44 bestanden
(waarvan omniORB 4.1.4-lp151.5.1 die hapert met desktop update – lukt wel met zypper – rest gaat wel door)

2021-01-06
OpenSUSE 15.1: gambas 2.24.0-lp151.61.2
50 tal bestanden over gambas en kde
(ook weer met KDE: bv kdebase3-runtime 3.5.10.1-lp151.3)

2020-11-30
OpenSUSE 15.1: gambas 2.24.0-lp151.57.49
Zijnde 43 gambas2 + 6 kde totaal 49 bestanden.
(ook weer met KDE: bv kdebase3-runtime 3.5.10.1-lp151.358.5)

2020-11-17 (ongeveer)
OpenSUSE 15.1: gambas 2.24.0-lp151.57.47
Zijnde 43 gambas* bestanden.
Samen met 6 KDE (kdebase3-runtime 3.5.10.1-lp151.358.3 etc); totaal 49 bestanden.

2020-11-09
OpenSUSE 15.1: gambas 2.24.0-lp151.57.46
Waaronder gambas2 runtime, gb-chart, gb-qt, qb-qt-kde, gb-settings, gb-v4l… In totaal een 43 packages, ook weer samen met kdebase/libs3/..-updates lp151.358.1 (6 packages)

2020-11-02
OpenSUSE 15.1: gambas 2.24.0-lp151.57.44
(samen met kdebase3 3.5.10.1-lp151.357.12 / kdelibs33.5.10-lp151.233.8)
(-)

2020-10-27
OpenSuse 15.1: gambas 2.24.0-lp151.57.43
(-)

2020-10-22* (-) Nota: gambas2 werkt(e) niet op 15.1
OpenSUSE 15.1: gambas 2.24.0-lp151.57.38
(ook kdebase3-runtime (3.5.10.1-lp151.357.5)
(-)

2020-10-19
OpenSUSE 15.1: gambas 2.24.0-lp151.57.37
(zowat alle files; ook samen met een kdebase3,kdelibs3 update)
(-)
Nota: gambas2 werkt(e) niet op 15.1
2020-10-02

OpenSUSE 15.1: gambas 2.24.0-lp151.57.34
Update van 2.24.0-lp151.57.32 KDE:KDE3 / openSUSE_Leap_15.1 openSUSE-Education.

* (-)
Nota: gambas2 werkt(e) niet op 15.1
Op 15.1 werkt(e) gambas2 niet: Segmentation fault (core dumped) (-)
Werkt niet bij een nieuw geïnstalleerde 15.1. Waarschijnlijk ontbreken bibliotheken of links naar de nieuwe versies van bibliotheken die misschien wel gemaakt zijn bij een doorlopend upgraden van versies.
zie ook http://gambas.copyleft.be/blog/archives/2102

2019-12-20
OpenSUSE 42.3: gambas 2.24.0-39.1
Inderdaad nog een update van 2.x build time 14/12!

29-11-2018: er komen nog steeds af en toe updates binnen (openSuse Leqp 42.3), zoals nu, van Gambas2: 2.24.0-33.1 (Gambas 2 blijft hoofd-versie 2.24)

---

19-4-2018: Er komt een update binnen voor Gambas 2 op openSUSE Leap 42.3.
Op datzelfde moment is er ook een upgrade voor kdebase3, de kernpaketten van kde3, die horen bij deze oude Gambas versie.
Samen zo’n 45 paketten voor Gambas2, 3 paketten voor Kde3.

kdebase gaat naar versie 3.5.10.1-330.3
gambas2 gaat naar versie 2.24.0-29.2

---

4-4-2018 Er komt een update (45 bestanden) binnen voor Gambas2 op openSUSE Leap 42.3.

Daarmee gaat die van …

2.24.0-24.58
Build Time:
za 03 mrt 2018 19:24:06 CET

naar …

2.24.0-24.59.
Build Time:
vr 30 mrt 2018 13:49:58 CEST

Als ik een tabel op het scherm zet (in de vorm van gridview, tableview, ..) ga ik ze meestal eerst initialiseren.

Bij het openen van het scherm Form_Open() roep ik de initialisatieprocedures aan, wat overzichtelijk is:

Public Sub Form_Open()
'
initGridImport()
init...
'
End

En als je later in je toepassing nieuwe inhoud moet weergeven kan je de init terug aanroepen om zeker te zijn dat alle vorige weergave weg is en de tabel terug goedstaat.

Ook de naamgeving van de kolomtitels of hoofden kan je in die init doen, dan vind je ze ook gemakkelijk terug. Ik ben onlangs begonnen met de kolomtitels omgekeerd te vullen zodat
– het aantal kolommen en de invulling ervan op een overzichtelijke manier aftelt; een anomalie valt sneller op.
– het gemakkelijker is er één toe te voegen nadien; bovenaan waar je het aantal wijzigt heb je onmiddellijk eronder de nieuwe kolomtitel.

Public Sub initGridImport()
' shows imported record id's and values
grvwImported.Header = GridView.Horizontal
grvwImported.Columns.Count = 4
grvwImported.Columns[3].Text = "values"
grvwImported.Columns[2].Text = "col-id"
grvwImported.Columns[1].Text = "ref-id"
grvwImported.Columns[0].Text = "id"
'
End

En onmiddellijk de kolombreedte is handig omdat je daar weet over welke kolommen het gaat:

grvwImported.Columns[3].Text = "values"
grvwImported.Columns[3].Width = 120


Het instellen van het aantal rijen kan je er ook doen, maar dikwijls zal je dat herhalen bij het hervullen, wat niet moet voor bv de kolomtitels.
grvwImported.Rows.Count = 0
' etc...

Misschien maak je een resetGridImport() waar dat inkomt.

De volgende stap bij het maken van een tabel met gegevens (TableView) is bepalen welke cel wel of niet mag gewijzigd worden. In dit artikel Hoe data in een cel steken van een TableView werd de tabel gecreëerd, en werd bij een klik de cel wijzigbaar met “.Edit”.

Vanaf je op een cel klikt, is die op het scherm wijzigbaar. De gegevens echt bewaren moet je verder zelf doen, maar misschien wil je al beperken welke cellen gewijzigd kunnen worden. Voorbeeld is een tabel die een record uit de databank weergeeft:

Kolom recordnummer, kolom veldnaam, kolom waarde in het veld. Die laatse willen we wijzigen.
Ik verkies een extra kolom voor de nieuwe waarde, waarbij de gebruiker nog kan zien wat er voordien stond.
Kolomtitels: “fieldname”, “current value”, “new value”
Kolom index 0, 1, 2; kolom 2 moet wijzigbaar zijn. (definieer bovenaan een constante voor deze kolom)

Public Const iColNewVal As Integer = 2

De rijen zijn de velden: rij 1 is id, tweede, derde enz zijn de andere velden van je record.
Je wil meestal niet dat het veld van de id kan gewijzigd worden.
Achteraan zit misschien nog een veld met de datum van aanmaak van het record, die moet ook hetzelfde blijven.

We maken een array om alle kolommen die wijzigbaar zijn in bij te houden:
Private arrEditMask As New Integer[]
Als Array.Find (van een rijwaarde) als resultaat -1 geeft komt ze niet voor.

Zet elke kolom erin die je nodig hebt:
arrEditMask.Add(i)

We reageren in de tabel op een klik als het een “wijzigbaar” veld is:

Public Sub TableView1_Click()
  
  Debug "Is current row ? = " & TableView1.Row
  Debug " is current column ? = " & TableView1.Column
  
  If TableView1.Column = iColNewVal
    If arrEditMask.Find(TableView1.Row) > -1
      TableView1.Edit()
    Endif
  Endif

End

En om de waarde te bewaren in de tabel (zichtbaar te maken na verlaten van het veld) moet je:

Public Sub TableView1_Save(x As Integer, y As Integer, sText As String)

      TableView1[x, y].Text = sText

End

Om de waarde te bewaren in het record in de databank moet je zelf verder uitwerken.

Een Gambas programma heeft een versienummer dat bestaat uit x.x.x, bv 0.0.1 als je net een nieuw project gestart hebt.
Het is in de IDE zichtbaar in Project, properties, en kan daar ook aangepast worden. Het wordt automatische verhoogd als je “compile” doet in de IDE. In code kan je het opvragen met Application.Version.

In een programma dat een databank gebruikt, hou ik ook bij welke versie lokaal geïnstalleerd staat, en wat de vorige versie was. Dat kan helpen in het oplossen van problemen, bv op het moment dat de struktuur van de databank verandert, en je dus zeker moet zijn met welke versie je werkt. Eigenlijk zou ik ook in de databank de minimumversie moeten bewaren bedenk ik nu, of misschien zelfs loggen user_id, version_used.

Ik heb geprobeerd zicht te houden op de versies die lokaal gebruikt worden, opgeslagen in de Settings File (~/.config/gambas/application.conf):

application.conf

[General]
..
Language="nl_BE"
Runcounter=1028
..
PreviousVersion="0.2.38"
LastVersion="0.2.38"
Version="0.2.38"
HighVersion="0.2.39"
LowVersion="0.2.10"
PreVersionDateOut=07/01/2016 13:24:07.426
...

Ik kan aflezen wat de laagste gebruikte versie is, wat de hoogste (soms schakel je terug naar een lagere versie na vastgestelde fouten bv), wat de huidige, voorgaande en wat de laatst gebruikte versie was.

Waarvoor ik in de module MCommon:

PRIVATE sLastError AS String

PUBLIC SUB storeVersion()
  ' check version settings exist
  IF NOT Settings["General/PreviousVersion"]  ' previous version number used (lower)
    Settings["General/PreviousVersion"] = Application.Version 
  ENDIF 

  IF NOT Settings["General/LowVersion"] ' lowest version used 
    Settings["General/LowVersion"] = Application.Version
  ENDIF 
 
  IF NOT Settings["General/HighVersion"] ' highest version used - kept when downgrading!
    Settings["General/HighVersion"] = Application.Version
  ENDIF 
  
  Settings["General/LastVersion"] = Settings["General/Version", ""] ' first save value before replacing it
  Settings["General/Version"] = Application.Version ' store version of current run 
  
  IF (Settings["General/Version"] <> Settings["General/LastVersion"]) ' up or downgrade?
    IF newestVersion(Settings["General/LastVersion"], Settings["General/Version"]) = Settings["General/Version"] ' upgrade
      Settings["General/PreVersionDateOut"] = Now() 
      Settings["General/PreviousVersion"] = Settings["General/LastVersion"]
      
    ELSE ' downgrade, check under lowest ?
      IF newestVersion(Settings["General/LowVersion"], Application.Version) = Settings["General/LowVersion"]
        Settings["General/LowVersion"] = Application.Version
      ENDIF 
    ENDIF 
    IF Settings["General/HighVersion"] <> Application.Version
      Settings["General/HighVersion"] = newestVersion(Settings["General/HighVersion", ""], Application.Version)
    ENDIF 
    
  ENDIF 
  Settings.Save

END

met de test :

PUBLIC FUNCTION newestVersion(sVersionA AS String, sVersionB AS String) AS String
  
  DIM sPart AS String
  
  DIM arrsPartsA AS String[]
  DIM arrsPartsB AS String[]
  
  DIM i AS Integer
  
  IF NOT sVersionA ' sVersionA is empty
    IF sVersionB 
      RETURN sVersionB
    ELSE ' AND sVersionB is empty
      RETURN ""
    ENDIF 
  ELSE IF NOT sVersionB ' sVersionB is empty
    RETURN sVersionA
  ELSE ' none is empty; compare parts to find out
    arrsPartsA = Split(sVersionA, ".")
    arrsPartsB = Split(sVersionB, ".")
  
    IF arrsPartsA.Count = arrsPartsB.Count
  
      FOR i = 0 TO (arrsPartsA.Count - 1)
        IF Val(arrsPartsA[i]) > Val(arrsPartsB[i])
          RETURN sVersionA
        ELSE 
          IF Val(arrsPartsB[i]) > Val(arrsPartsA[i])
            RETURN sVersionB
          ELSE 
            sLastError = "Part " & Str$(i + 1) & " of version number is the same " & arrsPartsA[i]
            DEBUG sLastError
          ENDIF 
        ENDIF 
        
      NEXT 
    ELSE 
      sLastError = "Could not detect versions; structure not the same: " & sVersionA & " <> " & sVersionB
      RETURN ""
    ENDIF 
    
  ENDIF   
  
END

en aangeroepen vanuit de eerst opstartende module, bv de klasse MMain (die opstartklasse is en nadien FMain aanroept):

MMain

 MCommon.storeVersion()