PB9 Problems

[Walt Decker]

1. PB9 Help - When reading through the descriptions of various controls there are often words missing. Where the words are missing there is a small indented box with a gray dot in the middle as if it was a missing graphic. Does anyone else have this problem? Is there a workaround for it?

2. In PB8 I could do something like this:

STATIC A() AS LONG
DIM A(0)

CALL SOMESUB(A())

SUB SOMESUB(A())

FOR I = 1 to SomeNum
  REDIM PRESERVE A(1 TO I)
NEXT I
END SUB

In PB9 I get a GPF unless I do something like DIM A(0 TO 0) at the start. I'm using XP Pro.

[Barry Erick]

You are missing the font used for those. They are underlined keywords or links. As for a fix... someone else may be able to help. I doubt they used anything but standard Windows Fonts.

[Gösta H. Lovgren-2]

1
2. In PB8 I could do something like this:

 
STATIC A() AS LONG
DIM A(0)
 
CALL SOMESUB(A())
 
SUB SOMESUB(A())
 
FOR I = 1 to SomeNum
  REDIM PRESERVE A(1 TO I)
NEXT I
END SUB

In PB9 I get a GPF unless I do something like DIM A(0 TO 0) at the start. I'm using XP Pro.

I think first a PBMain is needed (maybe not). This runs fine:

Function PBMain() As Long
Static A() As Long
Dim A(0)
Call SOMESUB(A())        
End Function
Sub SOMESUB(A() As Long)
Local Somenum, i As Long
For I = 1 To SomeNum
  ReDim Preserve A(1 To I)
Next I
End Sub

[Kev Peel]

From help:

When PRESERVE is specified, you can resize only the upper boundary of the last (outer) dimension of the array

So REDIM PRESERVE does not change the lower bound, you need to specify the correct lower bound, not 1 if it's 0, etc.
If the function is being passed arrays with different bounds, just use:

 
  REDIM PRESERVE arr([B]LBOUND(arr)[/B] To [I]n[/I])

[Walt Decker]

Barry:

I don't think that is the problem. Other underlined text and links show up. If I am missing a font the problem would be with all text of that nature.


Gösta:

Yes, your example will run fine because "SomeNum" = 0; therefore, it just falls through the FOR/NEXT without doing anything.

Kev:

There is only one dimension in an "n" dimensional array; therefore, the outer boundary is the "n" dimension.

DIM A(0) indicates that there is one element in A(). REDIM A(1 TO 1) indicates that there is still only 1 element in A(), and REDIM PRESERVE A(1 TO 1) indicates that there is still only 1 element in A(). Therefore:

DIM A(0)

FOR I = 1 TO 10
REDIM PRESERVE A(I TO I)
NEXT I

should work, at least it did in PB8.

[Eric Pearson]

Walt --

The PB/Win 8 docs also had the restriction against changing the lower bound when using REDIM PRESERVE. If it worked, it was a bug or fluke.

When PRESERVE is specified, you can resize only the upper boundary of the last (outer) dimension of the array.

-- Eric

[Gösta H. Lovgren-2]

Gösta:

Yes, your example will run fine because "SomeNum" = 0; therefore, it just falls through the FOR/NEXT without doing anything.

Yes you are right, Walt. It kicks out on A(1 to 1)

Function PBMain() As Long
Static A() As Long
Dim A(0) '<< Rem this and Error goes away.
Call SOMESUB(A())        
End Function
'
Sub SOMESUB(A() As Long)
  ErrClear
  Local Somenum, i As Long                               
 SomeNum = 10
For I = 1 To SomeNum
  ReDim Preserve A(1 To I)
 If Err Then
   ? Error$(Err) & Str$(Err),, "I =" & Str$(I)
   Exit Sub
 End If  
Next I  
 
   ? "Okay"
End Sub

If you rem out "Dim A(0)" then it runs fine. (IOWdon't Dim A() before the call.)

Note the code orignally posted (#1) gives a 484 error ("Static a() requires procedure" or words to that effect.) (Maybe it was not supposed to be compileable but I took it as such.)

=============================================
The characteristics of a popular politician:
a horrible voice, bad breeding,
and a vulgar manner.
Aristophanes
=============================================

[Dave Biggs]

1. PB9 Help - When reading through the descriptions of various controls there are often words missing. Where the words are missing there is a small indented box with a gray dot in the middle as if it was a missing graphic. Does anyone else have this problem? Is there a workaround for it?

See Steve's post in this thread for possible solutions. http://www.powerbasic.com/support/pb...ad.php?t=39282

[David Roberts]

From the docs:

It is best to enable #DEBUG ERROR error checking when developing a program. Once all of the more obvious bugs have been eradicated, you will want to return to the default setting (OFF), as this will make your code smaller and faster.

IMO, it would have been better to have the default ON, like #Tools, so just prior to finalization we turn them both OFF.

[David Roberts]

Walt, I wanted to comment on your reply to Kev but had to pop out.

An n-dimensional array has n dimensions, not one. If we wanted to discretely map three dimensional space, one way would be to use a three dimensional array. The length of each dimension would depend upon what lower and upper bounds we impose.

If two axes were allowed to collapse then we would have a 1-dimensional array representing a single axis/dimension of space.

If we stuck a pin at the origin, the starting point or lower bound, and another to the right, the end point or upper bound, then we may have, for example, A(0 to 9). If we wanted more space, and keep the data used so far, then we'd have to extend the axis to, say, A(0 to 15) ie increase the upper bound and move our pin up the line. Conversely, less space and we may go for, say, A(0 to 5) ie reduce the upper bound. This reduction, extension can only be achieved by moving the end point, the upper bound. The origin hasn't been pinned - it has been nailed by a sledgehammer.

Had we nailed our starting point at 1 then it too would not be allowed to move - only the pin to the right can move to give us more or less space and preserve data.

The reason why Eric's note must be adhered to is because an n-dimensional array is mapped into a single dimension or rather a 1-dimensional array of bytes - RAM - and in column order, not as most, well certainly me, would expect ie row order in which case we would be talking about the first (inner) dimension as opposed to the last (outer) dimension.

Of course, if we are not interested in preservation of data then none of the above applies since a REDIM is an ERASE followed by a DIM and having erased then we can dim what we like.

[Michael Mattias]

The reason why Eric's note must be adhered to is because....

... that is the documented and supported use.

The technical discussion may be fascinating, but the bottom line is, if the publisher says this is the way it must be used, then that is all you need to know.

[David Roberts]

if the publisher says this is the way it must be used, then that is all you need to know.

That is utter drivel.

Without understanding the first rung, we stand no chance on the second. Venture onto the third and we risk the chance of breaking our neck.

[Michael Mattias]

I must respectfully disagree, sir.

If the compiler publisher's documented capabilities, restrictions and limitations are "X" then any use beyond that is done at your own risk. IMNSHO that is very poor programming technique.

It may "work" in the sense it "creates correct output in this particular situation," but as pointed out in an earlier post here, it might be pure coincidence, also known as "dumb luck." ("Worked" only because OP had chosen to use a zero-lbound array).

[Gösta H. Lovgren-2]

I must respectfully disagree, sir.

Quelle surprise.

I have to go along with David on this one. For many of us (or at least the Dummies like me), the documentation (while always technically correct) is often obscure and/or over our heads. David's use of the Pin Analogy is clarifying. (Please resist expressing a pinhead remark. Thank you.)

=====================================
"You got to be careful i
f you don't know where you're going,
because you might not get there."
Yogi Berra
=====================================

[Michael Mattias]

For REDIM PRESERVE the documentation is neither obscure nor should be over anyone's head.

It reads "Thou Shalt Not Attempt to Change any Bounds Save the UBOUND of the Last Dimension Lest Thee Enjoyeth Failure"

[Walt Decker]

David R:

A one-dimensional array is an "n" dimensional array. A two-dimensional array is an "n X m" dimensional array. Your example illustrates a one-dimensional array with "x" number of elements. However, that's pitnicking and irrelevant to the discussion.

All I'm pointing out is a difference between 8 and 9. In 8, if I didn't DIM an array before DIMing / REDIM PRESERVEing / initializing it in a different SUB/FUNCTION I'd get a compile error stating that the array is not dimensioned when I tried to use it after DIMing / REDIM PRESERVing / initializing elsewhere. With PB9 that problem is fixed.

Dave B:

Thanks for the link to the help question. However, I don't know whether the help is using IE or Firefox which is my default browser. In most cases it isn't a problem since I can infer from the context what is missing, but sometimes I can't.

[Nick Luick]

Walt,

I thought so to, but there is more missing than you think. The square usually represents a link that opens a multiple selection window. As a temporary solution I copied the help file to another computer where it works properly, and check it when I need to know whats behind those magic squares.

Walt could you post your operating system and update version with graphics card ?

[Walt Decker]

Nick:

I'm using XP PRO SP2 and my adapter is Intel Q965/Q963 Express Chipset Family

[Trevor Lane]

What Kev said is right. When you dimension an array using DIM A(0) you create a one dimensional array using 0 as the base. If you wanted to use 1 as the base it should have been DIM A(1 to 1).

When you redim you cannot change the base. In the first example you set the lower bound as 0 so if you redim it with REDIM PRESERVE A(1 to 10) you are trying to change the base from 0 to 1.

Nothing nitpicking about that. I think you probably misunderstood what he said.

[Walt Decker]

Trevor:

I said nothing about that being nitpicking. The "pitnicking" was in reference to an entirely different thought.

However, there is one thing that has bothered me for a number of updates, actually since PBDLL days. That is unless an array is DIMed in the same procedure it is declared the compiler issues an "Array not dimensioned" message if it is subsequently used in the procedure it is declared.

For example:

LOCAL Ary()

Call Some_Sub(Ary(), Ubnd)

(compiler error here)

FOR I = 1 TO Ubnd
do something
NEXT I

END

Some_Sub(A(), Siz)
DIM A(1 TO 10)
END SUB

However, if it is DIMed first the compiler error goes away.