BBC BASIC for Windows: Startup

BBC BASIC for Windows
Programming >> BBC BASIC language >> Startup
http://bb4w.conforums.com/index.cgi?board=language&action=display&num=1279962623

Startup
Post by JB91 on Jul 24^th, 2010, 09:10am

In my program, I have an options dialog, and when you select an option it stays like that until you change it again. Is there a possible way to keep it changed when you close the program and start it again?

Josh.

Re: Startup
Post by admin on Jul 24^th, 2010, 09:23am

on Jul 24^th, 2010, 09:10am, JB91 wrote:

Is there a possible way to keep it changed when you close the program and start it again?

You would need to save the settings when you exit your program, and load them again when you next run it. You can either save them in the Registry, or an INI file. The INI file method is probably the easiest and safest for a beginner:

http://bb4w.wikispaces.com/Reading+and+writing+.INI+data+files

The Registry method is described in the main Help documentation:

http://www.bbcbasic.co.uk/bbcwin/manual/bbcwine.html#registry

Richard.

Re: Startup
Post by JGHarston on Aug 21^st, 2010, 4:55pm

on Jul 24^th, 2010, 09:23am, Richard Russell wrote:

The Registry method is described in the main Help documentation:
http://www.bbcbasic.co.uk/bbcwin/manual/bbcwine.html#registry

The simple registry library at http://bb4w.wikispaces.com/Simple+Registry+Usage
can make using the registry easier. For your example you might use something like:

Code:

option$=FNReg_Rd(KeyRoot$+"Options")
IF option$="" THEN option$=a default value
REM At this point ask user for (new) options
PROCReg_Wr(KeyRoot$+"Options",option$)

Jonathan

Re: Startup
Post by admin on Aug 21^st, 2010, 5:51pm

on Aug 21^st, 2010, 4:55pm, JGHarston wrote:

The simple registry library at http://bb4w.wikispaces.com/Simple+Registry+Usage
can make using the registry easier.

A question about FNReg_Rd:

Why is Buf% a global variable? Would it not be better for it to be declared LOCAL and renamed, say, B% in keeping with the other integer variables? Unnecessarily declaring a global variable within an FN or PROC is not good practice.

Richard.

Re: Startup
Post by JB91 on Aug 24^th, 2010, 4:49pm

I made an INI file, and coded my program to get data from it, but for some reason this code doesn't work in my program.

font$ = FNgetinistring(@usr$+"Settings.INI","options","font")
PRINT font$
*FONT font$
PRINT "Hello!"
END
DEF FNgetinistring(file$, section$, key$)
LOCAL buf%
DIM buf% LOCAL 255
SYS "GetPrivateProfileString", section$, key$, "", buf%, 256, file$
= $$buf%

Here is my simple INI file:

[options]
startupmax=NOT MAXIMISE
startupcol=11
startupbackcol=0
font=Times New Roman

Everything else works fine with INI files but when I run this code, it doesn't work.

Josh.

Re: Startup
Post by admin on Aug 24^th, 2010, 10:11pm

on Aug 24^th, 2010, 4:49pm, JB91 wrote:

I made an INI file, and coded my program to get data from it, but for some reason this code doesn't work in my program.
Code:

*FONT font$

You can't use *FONT that way. You must use OSCLI as follows:

Code:

      font$ = FNgetinistring(@usr$+"Settings.INI","options","font")
      PRINT font$
      OSCLI "FONT "+font$
      PRINT "Hello!"
      END

Also, you haven't specified a size for the font.

Richard.

Re: Startup
Post by JGHarston on Aug 30^th, 2010, 9:32pm

on Aug 21^st, 2010, 5:51pm, Richard Russell wrote:

A question about FNReg_Rd:
Why is Buf% a global variable? Would it not be better for it to be declared LOCAL and renamed, say, B% in keeping with the other integer variables?

I thought it was. My version here says v1.02 13Aug2007 Buf% localised (mdfs.net/blib/Win/Reg.bbc). I must have not correctly updated the wiki article, I'll go back and check.

Re: Startup
Post by JonR on Sep 5^th, 2010, 9:05pm

Why did you not change the code yourself when you spotted the error? A wiki wiki web site is by its nature a collaborative editing tool which all members are generally free to edit. Personally if I find an error in a wiki article I tend to correct it myself rather than contacting the original author who may no longer be interested in the wiki.

Re: Startup
Post by admin on Sep 5^th, 2010, 10:20pm

on Sep 5^th, 2010, 9:05pm, JonR wrote:

Why did you not change the code yourself when you spotted the error?

Quite simple - it didn't look anything like an 'error' to me. The indications were that the buffer pointer Buf% had quite deliberately been made a global: it was omitted from the list of LOCALs, and named according to the preferred convention for global variables (an initial capital and the rest lowercase). By contrast, the LOCAL integer variables were all 'static' - A% to Z%.

So the evidence pointed to it being a deliberate design decision to make the buffer pointer a global. In that case it would have been quite inappropriate to alter the article without first checking with the author.

I do commonly edit other people's Wiki articles to correct errors - when I'm certain it is an error; but I wasn't certain in this case. As it turns out it seems it really was just a mistake (but I still don't understand why the variable is named Buf% rather than B%).

Richard.

Re: Startup
Post by JGHarston on Sep 11^th, 2010, 10:45am

on Sep 5^th, 2010, 10:20pm, Richard Russell wrote:

(but I still don't understand why the variable is named Buf% rather than B%).

Don't worry, neither do I

It's probably the result of putting together the code on two seperate occasions, and cut&pasting working code into the library code rather than retyping it (which probably explains the missing LOCAL).
I may get around to changing it to B%, "Buf%" is not my usual nomenclature style anyway (I would usually use all lower case, or something more name descriptive).