sciencetalk

Ik maakte al diverse zelfstandig werkende programmas met QB 4.5 in .BAS uitvoering en die kun je normaal gesproken in je QB 4.5-programma omvormen tot een EXE file.

Bij het nieuwe programma gaf ik een normale opdracht:

input "staal of hout:" ;P en wat ik ook probeer met de opstelling ,er blijft een melding komen van :"EXPRESSION TOO COMPLEX".

Alle andere INPUT-opdrachten gaven geen problemen en konden probleemloos worden overgezet naar een EXE bestand;dus wat mankeert hier aan?

Aan de syntax zelf mankeert volgens mij niks. Als ik een simpel programmaatje in QB45 maak met die regel plus een PRINT P opdracht kan ik er zonder probleem een .exe van maken die zonder probleem loopt.

Als ik iets programmeer en niet begrijp waarom iets "fout" zou zijn dan delete ik de hele regel (incl carriage return), insert een nieuwe balanco regel en tik het hele commando overnieuw. Dit om zeker te weten dat er geen onzichtbare karakters zijn die blijkbaar een probleem vormden. Gewoonlijk helpt dat.

Ik ga je advies opvolgen en ben benieuwd naar het resultaat;bedankt voor de reactie!

Delete,return en commando opnieuw werkte niet!

Je kunt proberen de vorige opdracht op te splitsen als volgt:

print "staal of hout:" ;

input P

Dat geeft voor de werking van het basicprogramma hetzelfde resultaat.

Zou kunnen,het is soms echt een goocheldoos met programma's erbij.

Bedankt voor de begeleiding,als het weer mislukt ga ik proberen wat "print screens"" van de QB-reactie over te mailen!

Als dat ook niet werkt kan het probleem ook in de syntaxregel vóór, of de syntaxregel ná dat input statement zitten.

Het statement op zich is goed want bij mij werkt het.

Verder kan het iets met te veel geheugengebruik voor strings te maken hebben. Is P een string die je met DEFSTR P (of zelfs een hele range na DEFSTR) gedefinieerd hebt? Misschien is het beter die DEFSTR weg te halen en overal P$ te gebruiken en ook voor alle andere stringvariabelen een $ te gebruiken.

Het blijkt bovendien dat er een bug in QB zit waardoor de foutmelding ook onterecht op kan treden: http://support.microsoft.com/kb/38498

Dit is hetgeen wat ik in mijn programma zette en wat de reactie was bij de poging om dat over te zetten in een EXE-bestand.

Ik vertelde nog veel meer over veranderen van tekens en dat er veranderingen met alle overeenk.letters had plaats gevonden,maar dat was op advies van mijn geliefde vrouw,die mij vroeg om een de SH in j te wijzigen (was eenvoudiger).Aangezien j niet werkte ,de zaak weer omgezet in SH met gevolg dat alle aanwezige j's werden ge- SH't;

een feest was dat.

Ik poog nu verder omwegen,las het QB45 verhaal en zag dat de fout daar zat;wel laat,dat dat nu ontdekt wordt.



Ik hoop ,in de aandacht te blijven!

Als ik het goed begrijp heb je inmiddels dat INPUT statement opgesplitst in PRINT en INPUT maar dat helpt ook niet. En die P is eigenlijk die SH die je vrouw weer liever j zou noemen.

Je gebruikt verschillende keren PRINT #1 maar ik zie nergens een OPEN (filename) FOR OUTPUT AS #1 dus dat moet dan boven dat CLS statement staan?

Wat is het laatste serieuze statement (geen print of zoiets) boven het CLS statement ? Want dat is waarschijnlijk waar de foutmelding over gaat.

Als ik bijvoorbeeld het volgende simpele testprogrammaatje maak:

A = B / 0 'opzettelijke deling door nul

CLS

PRINT "staal of hout:"

INPUT SH

END

en dat compileer krijg ik de volgende foutmelding:

0030 x 0006 xx INPUT SH

xxxxxxxxxxxxxxxxxxxxx ^ Division by zero



terwijl het delen door nul toch drie regels hoger plaatsvond en bovendien niks met de variabele SH te maken had. Het probleem zit bij jouw wellicht ook enkele regels hoger dan de foutmelding doet vermoeden.

De filename-aanduiding gebeurt eerder en boven de foutmelding (bij de keus over staal of hout) staat m.i.niets bijzonders boven de eerst erboven gelegen CLS.

Maar ik worstel verder en bedankt voor de medewerking!

Moeten in de twee regels print de te printen benaming niet tussen "" staan ( voor én achter) ?

succes

Ik ben al druk bezig met Fred F om achter de problemen te komenmaar om een antwoord op je opmerking te geven:

Als je met QB werkt kun je in een programma het volgende zetten:

print "wat is het probleem?"



input "probleem is:",a

print"toets in a"

a=opgelost

als het goed is verschijnt er dan: opgelost

Maar dit soort problemen is niet de oorzaak m.i.Er zit een (bewuste?) bug in de QB45 onderdeel BC.exe en daar zijn mee we aan het kluiven,je mag mee doen.Mogelijk ontstaan door klonen volgens FF.

Is het jou-Clement- soms bekend of er bij de nieuwe QB4.5 een mogelijkheid bestaat om oude .BAS-bestanden om te zetten in .EXE-bestanden.Dezelfde vraag ging naar Flintstone (FF)!

Ik heb via internet zomaar een willekeurige QB4.5 zipfile gedownload en wel via: http://www.upseros.com/compiladores.php

Na downloaden en uitpakken zie ik dezelfde datum, tijd en bestandsgrootte als de QB files die ik al heel lang gebruik dus blijkbaar is het exact dezelfde build. Op mijn PC (windows XP SP2) met een testfiletje loopt het. Ook beide compileeropties werken en geven een exe file die runt.

Na uitpakken moet je eerst een snelkoppeling maken door met rechts te klikken QB.exe (273 kB) en de snelkoppeling daarna naar het bureaublad slepen. Klik op de snelkoppeling en je bent in de vertrouwde omgeving van QB 4.5

Er zit geen houdbaarheidsdatum op QB 4.5, niet op mijn originele, niet op bovenstaande.

Als het hiermee of eventueel andere gedownloade zips niet werkt moet het haast aan de PC liggen.

.bas files die lopen in de QB environment moeten zonder problemen gecompileerd kunnen worden tot .exe files, ik heb daar tenminste nog nooit problemen mee gehad.