Author |
Topic: Card graphics not sticking (Read 176 times) |
|
Turtleman
New Member
member is offline
Gender: 
Posts: 29
|
 |
Re: Card graphics not sticking
« Reply #46 on: May 24th, 2016, 10:38am » |
|
Richard: I'm so sorry to have gotten your name wrong in what must have been a momentary bout of dyslexia. I don't have a clue how I could have done that. Please forgive me!
I never set an "artificial requirement," but was merely curious about the speed differences. I thought (hoped) I was doing something wrong. Yes, perhaps that window and others could be loaded earlier and kept minimized until needed. Unfortunately, another window is used for plotting data repeatedly where speed is much more critical than opening the example code. With hundreds or thousands of data points, even a small difference in speed adds up. I expect that could be a "deal breaker," but will experiment further before giving up.
With thanks to tsh73, the example code used only consecutive numbers in the vertical label column, but in the real application, various numbers and letters are used, which might make it more difficult to simplify the code. I'm sure it can be done, where the labels can be fetched as data, but I haven't gotten around to working on that yet.
My LBB expectations were obviously misplaced, but am glad I gave it a go. And again, if nothing else, LBB is proving helping in identifying LB coding boo-boos!
|
| « Last Edit: May 24th, 2016, 10:39am by Turtleman » |
 Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Card graphics not sticking
« Reply #47 on: May 24th, 2016, 12:39pm » |
|
on May 24th, 2016, 10:38am, Turtleman wrote:| Unfortunately, another window is used for plotting data repeatedly where speed is much more critical than opening the example code. With hundreds or thousands of data points, even a small difference in speed adds up. |
|
I wonder if you have read the Wiki article Speeding up graphics plotting. In the very specific example given there it was possible, by making the suggested changes, to go from LBB plotting graphics noticeably more slowly than LB to it actually plotting more quickly.
Quote:| in the real application, various numbers and letters are used, which might make it more difficult to simplify the code. |
|
If those "various numbers and letters" are constants, they could for example be read from a DATA statement. If they are variables, then I would have expected that they could either be stored in an array or calculated at run-time as the boxes are populated.
Incidentally what is the reason that the main 'grid' is a single large graphicbox, whereas the row and column 'labels' are individual controls? I'm probably missing something, but it's not obvious to me why the row of horizontal labels shouldn't be a single graphicbox, and similarly the column of vertical labels, or indeed why the whole caboodle couldn't be a single graphicbox.
Quote:| My LBB expectations were obviously misplaced, but am glad I gave it a go. |
|
It was to make sure that your expectations were not "misplaced" that I said so early on that you should not expect graphics plotting to be any faster. I don't know whether you somehow missed that, or hoped that it wasn't true, but your realisation that LBB is not a panacea shouldn't have been a recent one!
The background, for those who are interested, is that since both LB and LBB simply pass graphics commands onto the Windows API, fundamentally they should execute at virtually the same speed (if anything LB would be expected to be a little slower because it is both plotting to the screen and recording the commands to a metafile). The reason LBB tends to be slower in practice is the overhead of interpreted BBC BASIC, which decodes the command strings.
It would, in principle, be perfectly possible for the existing BBC BASIC code to be replaced by (say) C or assembler code, which would almost certainly guarantee that graphics plotting is always faster in LBB than LB. But the very reason for LBB's existence is as a demonstrator of the capabilities of BBC BASIC, so from that point of view replacing it with code in another language makes no sense.
Richard.
|
|
Logged
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #48 on: May 26th, 2016, 4:37pm » |
|
This probably belongs in the Novice category on the LB board, but since it's already been suggested here to hide the window with "stylebits #main, 0, _WS_VISIBLE, 0, 0" and then "#main "show"" after loading, I have a related question.
If the "hidden" window is loaded at the start of the program, it can be made visible by manually issuing a "show" command when desired. That way the window appears to open immediately, which is highly desirable. QUESTION: How do you hide the window again once opened? The program crashes if issued a "#main "hide"" instruction, and simply closing the window takes me back to where I started. Perhaps relocating the window off-screen will work.
There are several windows (not all involving graphics) that can be toggled open or closed by the user, but I don't have enough experience to know how best to go about it. ANOTHER QUESTION: Is opening and closing the "normal" way of handling multiple windows or should they be loaded at the program's start and made visible or invisible as required? I hope that makes sense, and thanks to everyone for your patience.
Tsh73: Thanks to your help, a lot of unnecessary code has been eliminated.
|
|
Logged
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #49 on: May 28th, 2016, 4:58pm » |
|
Richard: Thanks for your explanations. Not knowing any better, I initially designed the program to open selected windows on demand. I'm now changing that to launch all windows along with the rest of the program – they're just hidden until needed. That eliminates any lag in populating the displays and tremendously simplifies the coding. (I often have a tendency to overcomplicate things!  ) So far, it looks like LBB might lend itself to running the program after all, but there're many more changes to make first.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Card graphics not sticking
« Reply #50 on: May 28th, 2016, 10:58pm » |
|
on May 28th, 2016, 4:58pm, Turtleman wrote:| Not knowing any better, I initially designed the program to open selected windows on demand. |
|
In the great majority of programs, it will make no noticeable difference which way you do it. Creating a window usually happens virtually 'instantaneously'; even in your own program it's not the window creation that takes a significant time but the window initialisation, i.e. filling all those graphicboxes and grid cells with a background color and text.
As I think I said previously, I've only once before encountered a program in which the window creation/initialisation took sufficiently longer in LBB than in LB to be important, so it's very unusual. On that occasion I could improve things somewhat, but not match the performance of LB.
I've suggested ways in which you could improve the performance of your program. To speed up window creation you could replace the horizontal set of column labels and the vertical set of row labels with single graphicboxes rather than many individual ones. To speed up the window initialisation you could concatenate the commands into one long string, as suggested in the Wiki article to which I linked.
But you never responded to either suggestion, which is why I concluded you weren't really motivated to get it working well in LBB. The code below incorporates both mods:
Code: 'Graphic boxes demo - May 23, 2016
nomainwin
start = time$("ms")
GridWidth = 40
GridHeight = 25
GridRows = 20
GridColumns = 10
MaxColors = 5
dim counters(GridColumns, GridRows), colors$(MaxColors-1)
restore [FieldValues]
for row = 1 to GridRows
for column = 1 to GridColumns
read n
counters(column, row) = n
next
next
restore [FieldColors]
for i = 0 to MaxColors-1
read color$
colors$(i) = color$
next
BoxWidth = GridColumns * GridWidth
BoxHeight = GridRows * GridHeight
WindowWidth = BoxWidth + 100
WindowHeight = BoxHeight + 100
UpperLeftX=int((DisplayWidth-WindowWidth)/2)
UpperLeftY=int((DisplayHeight-WindowHeight)/2)
graphicbox #main.gb2, 50, 10, BoxWidth, GridHeight
y = 15
graphicbox #main.gb1, 5, GridHeight + y, GridWidth, BoxHeight
graphicbox #main.gb, 50, 40, BoxWidth, BoxHeight
stylebits #main, 0, _WS_VISIBLE, 0, 0
open "Grid" for window as #main
#main, "trapclose [quit.main]"
#main.gb "down; font arial 10; size 1; color black"
#main.gb "when leftButtonUp [IncreaseCounter]"
#main.gb "when leftButtonDouble [IncreaseCounter]"
gosub [InitGrid]
gosub [title]
#main "show"
finish = time$("ms")
print finish-start
wait
[quit.main]
Close #main
END
[IncreaseCounter]
row = int( MouseY / GridHeight) + 1
column = int( MouseX / GridWidth) + 1
counters(column, row) = counters(column, row) + 1
if counters(column, row) > (MaxColors - 1) then counters(column, row) = 0
#main.gb "delsegment GridUpdate"
gosub [DrawField]
#main.gb "flush GridUpdate"
wait
[InitGrid]
for row = 1 to GridRows
for column = 1 to GridColumns
gosub [DrawField]
next
next
#main.gb "flush InitGrid"
return
[DrawField]
gb$ = "color black; backcolor "; colors$(counters(column, row)); ";"
gb$ = gb$ + "place "; (column-1)*GridWidth; " "; (row-1)*GridHeight; ";"
gb$ = gb$ + "boxfilled "; column*GridWidth; " "; row*GridHeight; ";"
gb$ = gb$ + "place "; (column-.6)*GridWidth; " "; (row-.4)*GridHeight; ";"
if instr(lower$(colors$(counters(column, row))), "dark") > 0 then gb$ = gb$ + "color white;"
gb$ = gb$ + "\"; counters(column, row)
#main.gb gb$
return
[FieldValues]
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
[FieldColors]
data "red" '0
data "darkgreen"'1
data "cyan" '2
data "yellow" '3
data "pink" '4
[title]
#main "font arial 12 bold"
#main "font arial 12 bold"
#main.gb2 "down; color black; backcolor yellow"
for i = 22 to 31
gb2$ = "place ";(i-22) * GridWidth; " 0;"
gb2$ = gb2$ + "boxfilled ";(i-21) * GridWidth; " "; GridHeight-2; ";"
gb2$ = gb2$ + "place ";(i-21.6) * GridWidth; " 17;\";i-21
#main.gb2 gb2$
next
#main.gb2 "flush"
'REM VERTICAL COLUMN LABELS ----------------------------------------------------------------------
#main.gb1 "down; color black; backcolor white"
for i = 1 to 20
gb1$ = "place 0 ";i * GridHeight; ";"
gb1$ = gb1$ + "boxfilled ";GridWidth-2; " "; (i-1) * GridHeight; ";"
gb1$ = gb1$ + "place 14 ";(i-0.4) * GridHeight; ";\"; i
#main.gb1 gb1$
next
#main.gb1 "flush"
return
Richard.
|
|
Logged
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #51 on: May 29th, 2016, 11:01am » |
|
Thanks again Richard. You've certainly demonstrated how the amount of code can be greatly reduced and initialization speeded up. The example I posted was just that, an example when I was concerned about the apparent slower speed. My actual application has nearly twice as many graphicboxes and the horizontal and vertical labels have a mix of one to five numbers, letters, and commas.
Thanks to tsh73, the code has been simplified a lot, but your example is much more elegant and efficient. Now, if I can just figure out how to integrate the word$ command to populate the labels with whatever's in the msg$ lines. Meanwhile, I've changed the window to initialize upon loading the program and it now pops up instantly fully populated. Some of the other windows may be modified accordingly. Regardless of LB or LBB, having more efficient code is always desirable; I'm just way too inexperienced to get there in one step.
I'm sorry I didn't respond to your previous post sooner, but even I have to sometimes do other things that take me away from the computer.  I am, however, highly motivated to get my program working well in LBB! It's identifying many areas in the code that can be improved, and making executables and changing icons (among other things) are way easier than in LB. If it eventually results in a speed increase won't be known for a while. Back later.
UPDATE: Son-of-gun, adding word$ and msg was a very simple change and it's a zillion times faster and simpler than my initial example. It's embarrassing! Now to modify my "real" program. I wonder if a centering command will work here or if I have to give exceptions for the place command on some lines.
|
| « Last Edit: May 29th, 2016, 11:57am by Turtleman » |
Logged
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #52 on: May 29th, 2016, 12:38pm » |
|
Another PS: Here's the small modification using Word$ and msg to permit characters to be used for the vertical column labels. That was easy. However, centering the labels within the column is so far eluding me. I've "played" with stylebits #main.gb, _ES_CENTER,0,0,0 with no success and guess there might be something to replace the "place 14 ";(i-0.4) * GridHeight instruction, but what?
Code:
'REM VERTICAL COLUMN LABELS ----------------------------------------------------------------------
msg$="10 A,B 3 4 5 6 7 8 C D E,F 14 15 10,10 11 G,G 17 18 19 20"
#main.gb1 "down; color black; backcolor white"
for i = 1 to 20
gb1$ = "place 0 ";i * GridHeight; ";"
gb1$ = gb1$ + "boxfilled ";GridWidth-2; " "; (i-1) * GridHeight; ";"
gb1$ = gb1$ + "font arial bold 10; place 2 ";(i-0.3) * GridHeight; ";\"; word$(msg$,i)
#main.gb1 gb1$
next
#main.gb1 "flush"
return
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Card graphics not sticking
« Reply #53 on: May 29th, 2016, 2:22pm » |
|
on May 29th, 2016, 12:38pm, Turtleman wrote:| I've "played" with stylebits #main.gb, _ES_CENTER,0,0,0 with no success |
|
As the _ES_ tells you, that's an Edit Style bit that is specific to a Texteditor or Textbox; it will have no effect on a Graphicbox.
Quote:| and guess there might be something to replace the "place 14 ";(i-0.4) * GridHeight instruction, but what? |
|
Find the width of the string in pixels, subtract it from the width of the box and halve the resulting value. That tells you at what horizontal coordinate within the box you need to draw the text so it will be centered. Easy, but it will make the code even slower!
Is the requirement to center the text just for the labels, or for the boxes in the main grid? I'm thinking that if it's only the labels maybe you would be better to use TEXTEDITOR controls rather than GRAPHICBOXes because then you could use the _ES_CENTER style bit. LB 4.5.0 and LBB provide control over the foreground and background color of texteditor controls.
Richard.
|
|
Logged
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #54 on: May 29th, 2016, 2:35pm » |
|
I probably shouldn't have mentioned the stylebits centering, as I realized after the fact that it wouldn't work in the graphicbox. Yes, the centering is only for the labels, and only for cosmetic reasons. In my original messy code, the individual place parameters could be adjusted to center labels of 1-5 characters. Obviously, a single graphicsbox is far superior from the standpoints of simplification and speed. Right offhand, I don't have a clue how to change over to substituting texeditor controls, but will definitely put it on the to-do list.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Card graphics not sticking
« Reply #55 on: May 29th, 2016, 4:02pm » |
|
on May 29th, 2016, 2:35pm, Turtleman wrote:| I don't have a clue how to change over to substituting texeditor controls |
|
Listed below for comparison purposes. It is slower (because we're back to individual controls for each label) and compatibility with LB must be abandoned, but the labels are centered with no extra effort.
Code: 'nomainwin
start = time$("ms")
GridWidth = 40
GridHeight = 25
GridRows = 20
GridColumns = 10
MaxColors = 5
dim counters(GridColumns, GridRows), colors$(MaxColors-1)
restore [FieldValues]
for row = 1 to GridRows
for column = 1 to GridColumns
read n
counters(column, row) = n
next
next
restore [FieldColors]
for i = 0 to MaxColors-1
read color$
colors$(i) = color$
next
BoxWidth = GridColumns * GridWidth
BoxHeight = GridRows * GridHeight
WindowWidth = BoxWidth + 100
WindowHeight = BoxHeight + 100
UpperLeftX=int((DisplayWidth-WindowWidth)/2)
UpperLeftY=int((DisplayHeight-WindowHeight)/2)
' Column label boxes:
for c = 1 to GridColumns
stylebits #main.te, _ES_CENTER or _ES_READONLY, _
_WS_HSCROLL or _WS_VSCROLL or _ES_MULTILINE, 0, 0
texteditor #main.te, c * GridWidth + 10, 10, GridWidth, GridHeight
maphandle #main.te, "#main.c";c
next
' Row label boxes:
for r = 1 to GridRows
stylebits #main.te, _ES_CENTER or _ES_READONLY, _
_WS_HSCROLL or _WS_VSCROLL or _ES_MULTILINE, 0, 0
texteditor #main.te, 5, r * GridHeight + 15, GridWidth, GridHeight
maphandle #main.te, "#main.r";r
next
graphicbox #main.gb, 50, 40, BoxWidth, BoxHeight
stylebits #main, 0, _WS_VISIBLE, 0, 0
open "Grid" for window as #main
hmain = hwnd(#main)
calldll #user32, "SetMenu", hmain as ulong, 0 as long, r as long
#main, "trapclose [quit.main]"
#main.gb "down; font arial 10; size 1; color black"
#main.gb "when leftButtonUp [IncreaseCounter]"
#main.gb "when leftButtonDouble [IncreaseCounter]"
#main.gb "setfocus"
gosub [InitGrid]
gosub [title]
#main "show"
finish = time$("ms")
print finish-start
wait
[quit.main]
Close #main
END
[IncreaseCounter]
row = int( MouseY / GridHeight) + 1
column = int( MouseX / GridWidth) + 1
counters(column, row) = counters(column, row) + 1
if counters(column, row) > (MaxColors - 1) then counters(column, row) = 0
#main.gb "delsegment GridUpdate"
gosub [DrawField]
#main.gb "flush GridUpdate"
wait
[InitGrid]
for row = 1 to GridRows
for column = 1 to GridColumns
gosub [DrawField]
next
next
#main.gb "flush InitGrid"
return
[DrawField]
gb$ = "color black; backcolor "; colors$(counters(column, row)); ";"
gb$ = gb$ + "place "; (column-1)*GridWidth; " "; (row-1)*GridHeight; ";"
gb$ = gb$ + "boxfilled "; column*GridWidth; " "; row*GridHeight; ";"
gb$ = gb$ + "place "; (column-.6)*GridWidth; " "; (row-.4)*GridHeight; ";"
if instr(lower$(colors$(counters(column, row))), "dark") > 0 then gb$ = gb$ + "color white;"
gb$ = gb$ + "\"; counters(column, row)
#main.gb gb$
return
[FieldValues]
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
data 0, 1, 2, 3, 4, 0, 1, 2, 3, 4
[FieldColors]
data "red" '0
data "darkgreen"'1
data "cyan" '2
data "yellow" '3
data "pink" '4
[title]
#main "font arial 10 bold"
' column labels:
for c = 1 to GridColumns
handle$ = "#main.c";c
#handle$ "!backcolor yellow"
#handle$ str$(c)
next
' row labels:
lbl$ = "one A,B 3 4 5 6 7 8 C D E,F 14 15 10 11 G,H 17 18 19 20"
for r = 1 to GridRows
handle$ = "#main.r";r
#handle$ "!backcolor lightgray"
#handle$ word$(lbl$,r)
next
return
I'm sorely tempted to replace those obsolete GOSUBs with CALLs, but have resisted the temptation so far!
Richard.
|
|
Logged
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #56 on: May 29th, 2016, 4:16pm » |
|
WOW - it probably would have taken me weeks or longer to do that if I could at all! I'm involved in something else at the moment and will need to spend some time trying to figure out why the latest code isn't compatible with LB. At this point, I'd still like to maintain compatibility, if for no other reason than to be able to compare performance later on. How big a job is it to modify centering code to be compatible?
Yes, I've heard that gosub's are almost as antiquated and nearly as verboten as goto's, but somehow find them easier to use than calls. I'm not sure I remember why calls are preferred, but gosubs are probably a nasty habit I picked up when I first started. Thanks a bunch!
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Card graphics not sticking
« Reply #57 on: May 29th, 2016, 4:39pm » |
|
on May 29th, 2016, 4:16pm, Turtleman wrote:| How big a job is it to modify centering code to be compatible? |
|
It's doable if you are prepared to lose the colored background to the labels. The problem with the !backcolor command is that only texteditor controls provide it, not textboxes, and in LB the _ES_CENTER stylebit only works with textboxes!
But you're on your own for making the changes; I draw the line at modifying programs to make them compatible with LB! Indeed I'm far more likely to make them incompatible with LB (if only accidentally).
Ideally I'd prefer not even to discuss on this forum how one might maintain compatibility with LB, because it's fundamentally contrary to what LBB is all about.
Quote:| Yes, I've heard that gosub's are almost as antiquated and nearly as verboten as goto's |
|
GOSUBs are worse than GOTOs! Getting rid of GOTOs, whilst worthwhile, can sometimes be tricky and require significant code changes. Replacing GOSUBs with CALLs is substantially trivial and GOSUB has no redeeming features at all.
Richard.
|
|
|
|
Turtleman
New Member
member is offline
Gender:
Posts: 29
|
|
Re: Card graphics not sticking
« Reply #58 on: May 29th, 2016, 4:46pm » |
|
Thanks - I understand completely. I'll try to stay more LBB-specific here, while most of my questions are generic programming related, anyway. I'll look into the reasons for using calls in place of gosubs and possibly become a convert.
Ron (Probably no need to remain as anonymous!)
|
|
Logged
|
|
|
|
tsh73
Full Member
member is offline
Gender:
Posts: 210
|
|
Re: Card graphics not sticking
« Reply #59 on: May 29th, 2016, 8:12pm » |
|
Quote:| and GOSUB has no redeeming features at all. |
|
It is a quick way to move piece of code away. Moving piece of code in a sub makes one to think of dependant varibles.
(and I missed some more then once, making program work wrong)
While in GOSUB one had access for all variables (kind of global)
|
| « Last Edit: May 29th, 2016, 8:13pm by tsh73 » |
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: Card graphics not sticking
« Reply #60 on: May 29th, 2016, 10:37pm » |
|
on May 29th, 2016, 8:12pm, tsh73 wrote:| It is a quick way to move piece of code away. |
|
I can think of only two reasons why you would ever want to "move a piece of code away". The first is when the same functionality is duplicated in two (or more) places in your program, so it is more efficient to create a 'shared' subroutine that can be called from both places. The second is when a section of code performs some relatively complex self-contained operation, which would make the program harder to read and understand if it is coded 'inline'.
In the first case it is important that the 'shared' subroutine can be called from multiple places without imposing artificial constraints on the calling code. For example it may make no sense for the two or more different places in the program to use the same variable names for the subroutine's inputs and outputs.
In the second case it is important that the calling program can be read and understood in isolation, without the detailed implementation of the subroutine being known. In particular the subroutine must not have unwanted 'side effects' such as modifying the values of variables that the calling code may be using.
Crucially, in both cases only a SUB (or a FUNCTION) meets these requirements. The inputs and outputs need not have the same variable names in the different places from which it is called, and any 'temporary' variables used within the subroutine are independent of those outside.
So my firm opinion is that GOSUB should never ever be used in a program written today. The sole purpose of GOSUB is to make it easier to port a legacy program that was originally written for an ancient version of BASIC that had no other kind of subroutine.
Richard.
|
|
Logged
|
|
|
|
|
