Newby: Class / UDT etc. problem.

[George Deluca]

I'm migrating what used to be a lot of GLOBAL data into a CLASS structure. The simple variables have migrated just fine; I'm now hitting the 1st of the odder types.

I'm stumped here on what is probably just a syntax problem, but I've read the Help over and over and gotten nowhere.

Below is a simple bit of test code which demonstrates the problem. My questions are:

1) I seem to be forced to DIM the UDT array in BOTH the Constructor and in the Method/Property. Great if its a fixed size, but what if it's a dynamically growing type that's REDIMed occasionally? I don't want fixed dimensions in the Method for sure.

2) Can the Method/Property return individual fields from a specific indexed entry in the UDT array? Or am I forced to return the whole UDT item? Just what is the syntax for this? I'm stumped.

As you can tell, I'm really lost here.

Here's the small test code. It sits as of my last trial, but I've gone through dozens of attempts, Properties, Methods, Returning individual UDT fields, returning the UDT.

TYPE TestType
   i AS LONG
   s AS STRING * 10
END TYPE

CLASS cTestClass
   INSTANCE Tests() AS TestType

   CLASS METHOD CREATE()                                 ' Constructor
      DIM Tests(10) AS TestType
      Tests(1).i = 333
      Tests(1).s = "String"
   END METHOD

   INTERFACE iTestClass: INHERIT IUNKNOWN                ' Define the interface
      PROPERTY GET Tests(BYVAL ix AS LONG) AS TestType
         DIM Tests(10) AS TestType
         PROPERTY = Tests(ix)
      END PROPERTY
   END INTERFACE
END CLASS

FUNCTION PBMAIN () AS LONG
LOCAL x      AS iTestClass
LOCAL Answer AS TestType
LOCAL j      AS LONG
   LET x = CLASS "cTestClass"
   Answer = x.Tests(1)
   MSGBOX "Data=" & FORMAT$(Answer.i)
END FUNCTION

[José Roca]

1) I seem to be forced to DIM the UDT array in BOTH the Constructor and in the Method/Property. Great if its a fixed size, but what if it's a dynamically growing type that's REDIMed occasionally? I don't want fixed dimensions in the Method for sure.

TYPE TestType
   i AS LONG
   s AS STRING * 10
END TYPE

CLASS cTestClass
   INSTANCE Tests() AS TestType

   CLASS METHOD CREATE()                                 ' Constructor
      DIM Tests(10) AS INSTANCE TestType
      Tests(1).i = 333
      Tests(1).s = "String"
   END METHOD

   INTERFACE iTestClass: INHERIT IUNKNOWN                ' Define the interface
      PROPERTY GET Tests(BYVAL ix AS LONG) AS TestType
         PROPERTY = Tests(ix)
      END PROPERTY
   END INTERFACE
END CLASS

FUNCTION PBMAIN () AS LONG
LOCAL x      AS iTestClass
LOCAL Answer AS TestType
LOCAL j      AS LONG
   LET x = CLASS "cTestClass"
   Answer = x.Tests(1)
   MSGBOX "Data=" & FORMAT$(Answer.i)
END FUNCTION

[José Roca]

2) Can the Method/Property return individual fields from a specific indexed entry in the UDT array? Or am I forced to return the whole UDT item? Just what is the syntax for this? I'm stumped.

Yes, it can.

TYPE TestType
   i AS LONG
   s AS STRING * 10
END TYPE

CLASS cTestClass
   INSTANCE Tests() AS TestType

   CLASS METHOD CREATE()                                 ' Constructor
      DIM Tests(10) AS INSTANCE TestType
      Tests(1).i = 333
      Tests(1).s = "String"
   END METHOD

   INTERFACE iTestClass: INHERIT IUNKNOWN                ' Define the interface
      PROPERTY GET TestsI(BYVAL ix AS LONG) AS LONG
         PROPERTY = Tests(ix).i
      END PROPERTY
   END INTERFACE
END CLASS

FUNCTION PBMAIN () AS LONG
LOCAL x      AS iTestClass
LOCAL Answer AS LONG
LOCAL j      AS LONG
   LET x = CLASS "cTestClass"
   Answer = x.TestsI(1)
   MSGBOX "Data=" & FORMAT$(Answer)
END FUNCTION

[Chris Holbrook]

xx

[George Deluca]

Jose: Many thanks. It's fine when you see it, but looking at Help and samples did me no good. Help is basically syntax diagrams and a dearth of examples.

I was pretty close on some of my attempts, but never quite got the right combination.

George

[George Deluca]

Sigh! I'm back.

Using Jose's sample, off I went to continue my conversion.

Below are the essential pieces from my latest attempt.

   INSTANCE Undo()      AS UndoType                      ' Array of Undo stuff

CLASS METHOD CREATE()                                 ' Constructor stuff
   LOCAL i AS LONG
   DIM Undo(10) AS INSTANCE UndoType                 ' Undo slot data
   FOR i = 1 TO 10
      Undo(i).Valid = %False
   NEXT i

It gets error 461 Array not dimensioned, pointing at the 1st character of Undo(i).Valid = %False

The DIM is 2 lines above the failing statement. What am I missing? The 1st compile errors were actually in the GET/SET property code, so I inserted the FOR/NEXT loop in the Constructor to see if it would work there, it didn't.

BTW: Valid IS a correct variable name in UndoType.

George

[José Roca]

Who knows what else do you have in the code you're not showing. Maybe a global array also called Undo...

This compiles:

#COMPILE EXE
#DIM ALL
#INCLUDE "win32api.inc"

TYPE UndoType
   valid AS LONG
END TYPE

CLASS cTestClass

   INSTANCE Undo()      AS UndoType                      ' Array of Undo stuff

   CLASS METHOD CREATE()                                 ' Constructor

      LOCAL i AS LONG
      DIM Undo(10) AS INSTANCE UndoType                  ' Undo slot data
      FOR i = 1 TO 10
         Undo(i).Valid = %False
      NEXT i

   END METHOD

   INTERFACE IFoo : INHERIT IUnknown
      METHOD Foo
      END METHOD
   END INTERFACE

END CLASS

FUNCTION PBMAIN () AS LONG

   MSGBOX "ok"

END FUNCTION

[George Deluca]

Jose: You're probably right, it must be something elsewhere.

It's hard to post larger extracts of the code; it's over 10,000 lines scattered over 5 BAS/INC files.

I had already modified my previous test posting just like you did to ensure the syntax worked, and it of course works perfectly.

I'm still looking.

George

[George Deluca]

Great big DUHH!!!

I won't embarrass myself any further by describing it.

Thanks again for the 1st clarification, sorry to bother you on this second one.

George

[Gösta H. Lovgren-2]

Great big DUHH!!!

I won't embarrass myself any further by describing it.

Thanks again for the 1st clarification, sorry to bother you on this second one.

George

By not telling us your error, George, you are not helping any of us to not embarassing ourselves by maybe being reminded to not make the same error. My guess is a Bounds error.

=================================================
"I'm all in favor of keeping dangerous weapons
out of the hands of fools.
Let's start with typewriters (word processors)."
Frank Lloyd Wright (1868-1959)
=================================================

[George Deluca]

Gosta: You're right. It was exactly as Jose suspected. I'd been moving stuff around so much between the various INC files as I restructured this beast, I'd simply forgotten exactly where things might be and didn't look in all places I should have. (Just laziness I guess)

If I'd spent a tiny bit more time in an proper search, I would not have wasted ?? times as much chasing this. And all your time as well.

George

[Michael Mattias]

I'd been moving stuff around so much between the various INC files as I restructured this beast, I'd simply forgotten exactly where things might be and didn't look in all places I should have. (Just laziness I guess)

You DO realize that with the latest compilers, the full path of all #INCLUDEd files appears in the *.log file, right?

eg

.....
Component Files:
----------------
D:\SOFTWA~1\pbwin90\Work\test_deletefolder_rb.bas
D:\SOFTWA~1\PBWIN90\WINAPI\WIN32API.INC

I've found that a really nice feature when I do "rearranging" just like you are doing.

MCM

[George Deluca]

Michael:

Yes, I was aware of that. I've been trying to get some semblance of order into a program that had just grown into a big unwieldy monster. So I've been trying different groupings of stuff into logical INC files, and also starting to use CLASSes to help further coming changes.

I'm doing this in small migratory steps rather than as one big make-all-the-changes-at-once and then fight for a clean compile and test project. Especially as my OOp knowledge is non-existant (as has been obvious). This way each small step still results in a clean compile and execution before the next batch of changes.

It may not be the most efficient process, but it's the way I've always worked. However it does mean at times that both old and new code is still present (some commented out or in routines no longer called). I tend not to delete old code completely till I'm fully satisfied with the new stuff. This does make it harder to spot duplicate definitions though.

And yes, it can cause the problems I've been going through. I can usually spot these readily. Maybe because I'm on the OOp learning curve I tended to assume yet another stupid coding error on my part rather than the more basic duplication error.
George

[Michael Mattias]

I did find this interesting...

Component Files:
----------------
D:\SOFTWA~1\pbwin90\Work\test_deletefolder_rb.bas

Part of the file name in long file name format, part in short file name format. You don't see that every day, do you?