Control Set Text ???? Not Working 100% ???

[Robert Alvarez]

This is part of a progarm that displays a 5 row with 6 columns (C1 thru C6) of
data from a file.

Problem is there are two locations that do not display what the record
file "DSP_TEST.DAT" has for data. Where 5A should be it is blank and where
3E should be it displays 5A. I have tried eveything I could and can not
see where there is a bad line of code to causes this.

There is also a part of the program which blanks out data if no data is
available in the file, but I added text with a # symbol to see what is
happening. It also display a blank where #5a should be and #5a where
#3e should be.

Looking at the data file with notepad, everything there looks OK except when
displayed in the program.

Problem seem to be on row 3 and 5 only. When doing PRV (previous)

Anyone who tries to help me solve this bug should make a file with the following
data as follows:

1A 1B 1C 1D 1E 1F
2A 2B 2C 2D 2E 2F
3A 3B 3C 3D 3E 3F
4A 4B 4C 4D 4E 4F
5A 5B 5C 5D 5E 5F
6A 6B 6C 6D 6E 6F

Help is appreciated here.

Thanks
Robert

[Gösta H. Lovgren-2]

I looked at your code, Robert, but was unable to find anything wrong.

However one thing did jump out at me - It seems to me a program that is crying out for the use of arrays. Be a LOT simpler than using all those variables. Be much easier to debug too, I think.

===================================
"The secret of (political) success
is honesty and fair dealing.
If you can fake those,
you've got it made."
Groucho Marx
===================================

[Gösta H. Lovgren-2]

Okay Robert. Just for funsies I've been playing around with your program and I get the same results as you do.

Here's something REALLY peculiar:

...
Control Set Text hDlg, %LBL15, "test " & RC3 '<-- Prints "test"
Control Set Text hDlg, %LBL16, "test " & ColA3 '  " "
Control Set Text hDlg, %LBL17, "test " & ColB3 '  " "
Control Set Text hDlg, %LBL18, "test " & ColC3 '  " "
Control Set Text hDlg, %LBL19, "test " & ColD3 '  " "
Control Set Text hDlg, %LBL20, "test " & ColE3 '<-- Does not print "test"
Control Set Text hDlg, %LBL21, "test " & ColF3 '  Prints "test"
...

%Lbl20 does not display the word "test" but the others do. {Hmmmm....}

'A few minutes later {trumpets blaring}

FOUND the error (I think). %lbl30 was set to 220 (same as %Lbl20). Chgd to 230 and it displays fine.

 %LBL1=201:  %LBL2=202:  %LBL3=203:  %LBL4=204:  %LBL5=205:  %LBL6=206:  %LBL7=207:  %LBL8=208:  %LBL9=209: %LBL10=210
%LBL11=211: %LBL12=212: %LBL13=213: %LBL14=214: %LBL15=215: %LBL16=216: %LBL17=217: %LBL18=218: %LBL19=219: %LBL20=220
%LBL21=221: %LBL22=222: %LBL23=223: %LBL24=224: %LBL25=225: %LBL26=226: %LBL27=227: %LBL28=228: %LBL29=229: [B][U]%LBL30=230 ' <-- error - was 220
[/U][/B]%LBL31=231: %LBL32=232: %LBL33=233: %LBL34=234: %LBL35=235: %LBL36=236: %LBL37=237: %LBL38=238: %LBL39=239: %LBL40=240
%LBL41=241: %LBL42=242: %LBL43=243: %LBL44=244: %LBL45=245: %LBL46=246: %LBL47=247: %LBL48=248: %LBL49=249: %LBL50=250
%LBL51=251: %LBL52=252: %LBL53=253: %LBL54=254: %LBL55=255: %LBL56=256: %LBL57=257: %LBL58=258: %LBL59=259: %LBL60=260

===================================
Speech is human,
silence is divine,
yet also brutish and dead:
therefore we must learn both arts.
Thomas Carlyle
===================================

[Rodney Hicks]

Uh, I ... well...

[Robert Alvarez]

Gösta

That's it. My bug is gone.
Yes arrays have more power too in PB, something to do later on.

Thanks for your help!

[Michael Mattias]

Yes arrays have more power too in PB, something to do later on.

Looking at the problems you caused yourself by not using arrays here, wouldn't "now" be a better choice than "later?"

I wouldn't even use all those separate label equates. I'd use something like

%ID_LABEL_BASE = 201 
  ...

   FOR Z = 1 TO whatever 
     CONTROL ADD LABEL hDlg, %ID_LABEL_BASE + Z,  (xpos based on Z), (pos based on Z)...
  NEXT

I think I have a demo which does this which should get you started. Let me look...

...yes....here it is. It's not in the Source Code forum but it should give you an idea.

http://www.powerbasic.com/support/pbforums/showpost.php?p=163014&postcount=11

But you can be very happy about one thing: you weren't paying someone a buck-and-a-half a minute to find a silly error like this.


MCM

[Rodney Hicks]

Once again, for the record, there is nothing wrong with CONTROL SET TEXT as the thread title implies.

Rod

[Cliff Nichols]

%lbl30 was set to 220 (same as %Lbl20).

This sort of thing happened to me, that a menu item stopped working in 1 version of my software, but for years had worked fine.

Thats when I realized that I had accidentally set a future item (while working on future updates) I had set to the same value, and did not know it.

Glad I caught it before it gets released to the public.

Hmmm....makes me think I should write a program (if one is not already done) that checks all constants and reports duplicates, so I can avoid problems such as this

[Robert Alvarez]

MCM

Back a good while ago I tried to understand arrays. The simple one
dim array was OK, but the mult dim type, got lost with that.

I will study your sample code and search the forum for other
samples to study.

[Nick Luick]

When I started programming I avoided arrays for lack of understanding (self taught).

One method that may help is to imagine a rectangle with a group of smaller boxes within, much like post office boxes or the message boxes in the lobby of a hotel, or the grid of a map. How these boxes are usually identified is a combination of letters and numbers.

A simple example is a map grid labeled say from A to F and 1 to 6. If I ask you to look at the section of the map C3, you would focus on the information in the box under column C and line 3. This is the same for arrays, except numbers are used for both columns and rows and in this case of C3 should be the information in grid or array 3,3. If you have trouble or get confused create a small array of say Test(6,6) and fill it with some information, and then display it using FOR NEXT loops.

I promise you that once you practice a little you will never create individual values for this type data again. There are also many other advantages using arrays such as adding a increment to all data or transposing the data set to another array.

[Gösta H. Lovgren-2]

MCM

Back a good while ago I tried to understand arrays. The simple one
dim array was OK, but the mult dim type, got lost with that.

I will study your sample code and search the forum for other
samples to study.

Maybe this will help you get started, Robert. See how just a few lines of code replaces tons of literal and makes code easier to read as well.

Sub Setup_Arrays
  Local Row&, Column&, Counter&
 
  'Replace literal addresses with a simple array
' %LBL1=201:  %LBL2=202:  %LBL3=203:  %LBL4=204:  %LBL5=205:  %LBL6=206:  %LBL7=207:  %LBL8=208:  %LBL9=209: %LBL10=210
'%LBL11=211: %LBL12=212: %LBL13=213: %LBL14=214: %LBL15=215: %LBL16=216: %LBL17=217: %LBL18=218: %LBL19=219: %LBL20=220
'%LBL21=221: %LBL22=222: %LBL23=223: %LBL24=224: %LBL25=225: %LBL26=226: %LBL27=227: %LBL28=228: %LBL29=229: %LBL30=230 ' <-- error - was 220
'%LBL31=231: %LBL32=232: %LBL33=233: %LBL34=234: %LBL35=235: %LBL36=236: %LBL37=237: %LBL38=238: %LBL39=239: %LBL40=240
'%LBL41=241: %LBL42=242: %LBL43=243: %LBL44=244: %LBL45=245: %LBL46=246: %LBL47=247: %LBL48=248: %LBL49=249: %LBL50=250
'%LBL51=251: %LBL52=252: %LBL53=253: %LBL54=254: %LBL55=255: %LBL56=256: %LBL57=257: %LBL58=258: %LBL59=259: %LBL60=260
 
'replace all of the above with this:
  Global Label_Addresses(5, 1 To 10) '6 rows, 10 columns
  Counter = 200 'start addresses from here
  For Row = 0 To 5 
     For Column = 1 To 10 
       Incr Counter
       Label_Addresses(Row, Column) = Counter
     Next Column
  Next Row
'now replace RC literals
  Global RC$()
  Dim RC(1 To 20) As String
 
'Global RC1  As String, RC2 As String,  RC3 As String,  RC4 As String,  RC5 As String
'Global RC6  As String, RC7 As String,  RC8 As String,  RC9 As String,  RC10 As String
'Global RC11 As String, RC12 As String, RC13 As String, RC14 As String, RC15 As String
'Global RC16 As String, RC17 As String, RC18 As String, RC19 As String, RC20 As String
 
' now replace all this with a simple array
'Global ColA1 As String, ColA2 As String, ColA3 As String, ColA4 As String, ColA5 As String
'Global ColA6 As String, ColA7 As String, ColA8 As String, ColA9 As String, ColA10 As String
'Global ColA11 As String, ColA12 As String, ColA13 As String, ColA14 As String, ColA15 As String
'Global ColA16 As String, ColA17 As String, ColA18 As String, ColA19 As String, ColA20 As String
'
'Global ColB1 As String, ColB2 As String, ColB3 As String, ColB4 As String, ColB5 As String
'Global ColB6 As String, ColB7 As String, ColB8 As String, ColB9 As String, ColB10 As String
'Global ColB11 As String, ColB12 As String, ColB13 As String, ColB14 As String, ColB15 As String
'Global ColB16 As String, ColB17 As String, ColB18 As String, ColB19 As String, ColB20 As String
'
'Global ColC1 As String, ColC2 As String, ColC3 As String, ColC4 As String, ColC5 As String
'Global ColC6 As String, ColC7 As String, ColC8 As String, ColC9 As String, ColC10 As String
'Global ColC11 As String, ColC12 As String, ColC13 As String, ColC14 As String, ColC15 As String
'Global ColC16 As String, ColC17 As String, ColC18 As String, ColC19 As String, ColC20 As String
'
'Global ColD1 As String, ColD2 As String, ColD3 As String, ColD4 As String, ColD5 As String
'Global ColD6 As String, ColD7 As String, ColD8 As String, ColD9 As String, ColD10 As String
'Global ColD11 As String, ColD12 As String, ColD13 As String, ColD14 As String, ColD15 As String
'Global ColD16 As String, ColD17 As String, ColD18 As String, ColD19 As String, ColD20 As String
'
'Global ColE1 As String, ColE2 As String, ColE3 As String, ColE4 As String, ColE5 As String
'Global ColE6 As String, ColE7 As String, ColE8 As String, ColE9 As String, ColE10 As String
'Global ColE11 As String, ColE12 As String, ColE13 As String, ColE14 As String, ColE15 As String
'Global ColE16 As String, ColE17 As String, ColE18 As String, ColE19 As String, ColE20 As String
'
'Global ColF1 As String, ColF2 As String, ColF3 As String, ColF4 As String, ColF5 As String
'Global ColF6 As String, ColF7 As String, ColF8 As String, ColF9 As String, ColF10 As String
'Global ColF11 As String, ColF12 As String, ColF13 As String, ColF14 As String, ColF15 As String
'Global ColF16 As String, ColF17 As String, ColF18 As String, ColF19 As String, ColF20 As String
'
 Global Cols$()
 Dim Cols(1 To 6, 1 To 20) As String
'make it even easier to follow in code
 Global a&, b&, c&, d&, f&
  a = 1
  b = 2
  c = 3
  d = 4
  e = 5
  f = 6
 'ColF17 would be Col(f, 17)
 'ColE1  would be Col(e, 1)
End Sub

[Michael Mattias]

When I started programming I avoided arrays for lack of understanding (self taught).

Don't feel alone.

I did a COBOL-lanngauge contract job for a "major corporation." As it was my first contract for them, the lead programmer wanted to review my source code before she would sign off on the job; totally reasonable.

Imagine my surprise when she told me not only was my work "OK", but she was glad she had reviewed my code because it was the first time in her nine years of experience as 'lead programmer' she had ever seen the SEARCH verb used.

(COBOL 'SEARCH' is roughly the equivalent of PB 'ARRAY SCAN' )

Taught me to never assume any level of skills or competence.

MCM

[Chris Holbrook]

...it was the first time in her nine years of experience as 'lead programmer' she had ever seen the SEARCH verb used.

ISTR that SEARCH was hideously inefficient in some compilers and would have been a candidate for "outlawing" by Operations departments (in the days when it took three shifts of a dozen operators to keep a 192K monster running round the clock).

[Michael Mattias]

>ISTR that SEARCH was hideously inefficient in some compilers

I never heard that. SEARCH is almost univerally implemented as a sequential trip thru the table, looking for 'condition'

eg

    SET Table-index to +1
    SEARCH Foo
        AT END 
            MOVE FALSE to found 

        WHEN foo(Tableindex) equal target
            MOVE TRUE To Found 
   
    END-SEARCH

Pretty much the same as

  FOR Z = LBOUND (Foo,1) TO UBOUND (Foo,1) 
     IF Foo(Z) = Target then 
         EXIT FOR 
    END IF 
  NEXT

However, what *was* and often still is inefficient for a number of compilers was to do a linear search NOT by use of the SEARCH verb, but by use of a subscript varied with the 'PERFORM VARYING' syntax, e.g,

  MOVE FALSE to found 
  PERFORM VARYING subscript 
    from 1 BY 1 
    UNTIL subscript GREATER numberofTableElement s
      IF foo (subscript) = Target 
        MOVE TRUE to FOUND
         exit perform 
     end-if
  END-PERFORM

"PERFORM VARYING" is known to be a stone loser with several compilers (eg IBM mainframe up through at least the first release for Z/OS).




MCM

[Chris Holbrook]

"PERFORM VARYING"

certainly wrote hundreds of those! Maybe it was an architectural issue, or maybe I have "misremembered". The kit I worked on was very different from IBM 360 architecture. Mostly COBOL 74. We were very performance-sensitive and if there was any advantage in using it, it would have been "search" all the way.

Come to think of it, doesn't the 360 architecture have a neat way of indexing tables in store? Maybe SEARCH exploits that particularly well.

[Michael Mattias]

It's not the hardware, its the compiler.

IBM mainframe COBOL compiled actual OFFSETS into the compiled code, eg instead of indexing 'as needed' at runtime, it compiled Subscript(N-1)*SIZE(table-element) when tables are accessed using an index dataname. You did not get this benefit if you used a subscript, although that is legal and gets the correct answer.

Come to think of it, maybe the performance hits were because if the use of a subscript instead of an index?

PB rough equivalent:
Subscripts

  FOR Z = 1 TO 10 
     IF Foo(Z) = 12 THEN 
        do something
     END IF 
  NEXT

Offsets

 LOCAL pVar AS sometype PTR 
 pVar = VARTPR (Foo(0)) 
 FOR Z = 1 TO 10  
    IF @pVar = 12 THEN 
        do something
    END IF 
    INCR pVar 
 NEXT

Curiously enough, using offsets is faster in PB, too.

MCM