Hoewel heel het project vertaald is en volledig in het NL draait, is een deelvenster FEdit plots helemaal in het Engels. Het verschil met de andere Forms is dat de teksten op het scherm geschreven worden vanuit code :
txtlb.text=”Titel op scherm”
Wordt deze teksttoewijzing in code niet mee aangeboden bij het vertalen?
Upd 26/6: Om teksten in code in de vertaal-lijst te krijgen moet je ze voorzien van extra haakjes:
txtlb.text=("Titel op scherm")
Project, Translate geeft deze fout:
Over welke packages gaat het hier concreet?
Een zoek naar “gnu translation tools” levert geen resultaat in Yast.
Upd:
Raadpleging op web : het gaat waarschijnlijk over de gettext tools; ik selecteer in Yast2 dus
gettext-tools - Tools for Native Language Support (NLS)
Ok! (zie ook hier)
Ik las onlangs een commentaar van Benoit Minisini waarin hij (vertaald) zegt:
Doe nooit:
sql = "INSERT INTO klant (naam) VALUES ('" & TextBox1.Text & "')"
res = mDatabase.conn.Exec(sql)
maar doe:
res = mDatabase.conn.Exec("INSERT INTO klant (naam) VALUES (&1)", TextBox1.Text)
Voorbeeld met een nieuw project, graphical application met: DB access.
Table test bevat velden:
' Gambas class file
|
FMain
Run
De code onder knop 1 geeft volgende foutmelding:
De code onder knop 2 werkt (is gemaakt volgens opmerking boven). Knop 3 gebruikt string sSql om query toch eerst op te bouwen.
PUBLIC SUB btInsert3_Click() DIM sSql AS String sSql = "INSERT INTO test (naam, opm) VALUES (&1, &2)" Ook in een select kan dat gebruikt worden, bv: |
Ik vul de datum in vanuit een Gambas programma met een string sDocDate die de datum in het formaat “2008-07-31” bevat.
Als ik het record ophaal, eventueel wijzig en terug bewaar, krijg ik echter een lege datum in de databank, waarschijnlijk als gevolg van een foute invoer.
Als ik naar het formaat kijk waarin de datum weergegeven wordt zie ik al het probleem: een andere datumindeling: “07/31/2008”, dus eerst de maand, dan de dag en dan het jaar. (op het scherm met txbxDate.Text= $hInvoice.sInvDate)
Als diezelfde string terug bewaard wordt, of vervangen wordt door een andere onjuiste datum-vorm onstaat een probleem.
Oorzaak is waarschijnlijk de localisatie (US) van het systeem waar ik nu op werk.
Dat valt te voorkomen door de datumstring die je ophaalt om te zetten in een datum en daarna terug te formatteren als datum zoals je die wil:
txbxDate.Text = Format(CDate(FMain.$hInvoice.sInvDate), "yyyy-mm-dd")
Achtergrond: Continue reading
Het leegmaken* van de eigenschappen van een object vanuit de classe kan met verwijzing
(* ik bedoel hiermee het op 0 zetten voor getallen en het “” zetten van een string)
naar zichzelf met “ME”:
' Class voorbeeld
PUBLIC LongName AS String
PUBLIC Amount AS Float
...
PUBLIC Empty
WITH ME
.LongName = ""
.Amount = 0
END WITH
...
In de . notatie komen de PROPERTY eigenschappen voor, je zou dus kunnen denken:
' Class voorbeeld
PUBLIC LongName AS String
PUBLIC Amount AS Float
PROPERTY Named AS String
PROPERTY READ Numbered AS Integer
...
PUBLIC Empty
WITH ME
.LongName = ""
.Amount = 0
.Named = ""
.Numbered = 0
END WITH
...
Je krijgt geen foutmelding voor .Named = “”
Je krijgt wel een foutmelding voor .Numbered = 0 (“is read only”)
Blijkbaar wordt dus de “automatische” _Write methode aangesproken, die niet bestaat voor het READ-only PROPERTY (enkel leesbaar).
Je moet in de plaats daarvan de eventueel intern gebruikte variabelen op nul zetten:
' Class voorbeeld
PUBLIC LongName AS String
PUBLIC Amount AS Float
PROPERTY Named AS String
PROPERTY READ Numbered AS Integer
PRIVATE $sNamed AS String
PRIVATE $iNumbered AS Integer
...
PUBLIC Empty
WITH ME
.LongName = ""
.Amount = 0
END WITH
$sNamed = ""
$iNumbered = 0
END
...
PRIVATE SUB Named_Write(Value AS String)
$sNamed = Value
END
Kan je met twee objecten:
huidigObjectiets doen als:
vorigObject
vorigObject = huidigObject
Ja, dat gaat inderdaad. Is het ook ok? Wat gebeurt met het vorigObject? Worden alleen de waarden intern overgenomen? Of wijst vorigObject nu naar huidigObject?
Gambas heeft een ingebouwd commando DEBUG.
Je kan het gebruiken om iets naar de “console” te sturen, m.a.w. het te tonen via de standaard uitvoer, in de programmeeromgeving (zie schermafdruk).
De DEBUG instructie geeft meer weer dan PRINT; je krijgt in volgorde de naam van de class, de naam van de methode, en tenslotte het regelnummer (van de regel waarin de op dat moment uitgevoerde DEBUG staat).
Bovendien worden, binnen de Gambas omgeving, bij het maken van een “executable” (een uitvoerbaar programma) de DEBUG lijnen uitgefilterd; ze bezwaren je code dus niet. En als je ze er toch uitwil kan je ze gemakkelijk vinden; en ook makkelijk het onderscheid maken met de gewone PRINT instructies.
Op de schermafdruk ook de zoek functie; die maakt onderscheid tussen hoofd-en kleine letters. Soms lijkt “zoek” niet goed te werken, maar komt dat door de instelling: je kan zoeken in de huidige tekst, alleen binnen de huidige procedure, of binnen het hele project.
Los van het feit dat het menu er gisterenavond dus niet als Gambas-programmeren uitzag, heeft de titel absoluut niets te maken met de pagina over gambas die ik net vond: aflevering 40 van “Brave Gnu World”, van 2002 schat ik.
Daarin wat uitleg over Gambas, en de anekdote waarin Benoît zijn dual-boot windows/linux systeem zit te tunen; hij formatteert vanuit dos zijn harde schijf – helaas de verkeerde, nl die waar Gambas opstond. En natuurlijk geen backups. Uiteindelijk vindt hij nog een toevallige kopie van een maand voordien…
