TYPES aren't allowed below SUBs with parameters of said TYPE

[SMcNeill]

Some quick code for illustration:

This works:

Code: QB64: [Select]

1. SUB Foo
2.     TYPE UDT
3.         AS INTEGER X, Y, Wide, High
4.     END TYPE
5. END SUB
6.  
7. SUB Foo2 (Whatever AS UDT)
8.  
9. END SUB

This doesn't work:

Code: QB64: [Select]

1. SUB Foo2 (Whatever AS UDT)
2.  
3. END SUB
4.  
5. SUB Foo
6.     TYPE UDT
7.         AS INTEGER X, Y, Wide, High
8.     END TYPE
9. END SUB

And this doesn't work:

Code: QB64: [Select]

1. SUB Foo2 (Whatever AS UDT)
2.     TYPE UDT
3.         AS INTEGER X, Y, Wide, High
4.     END TYPE
5. END SUB

Which, leaves the impression to me, that TYPES are a Top-to-bottom style definition object, much like _DEFINE is.  It only seems to come into code when first placed, and can't be referenced prior to that, when referenced via SUB or FUNCTION.

Of course, this *ONLY* applies when being passed via a parameter, as we can see from the below, which is perfectly fine:

Code: QB64: [Select]

1. SUB Foo2
2.     DIM whatever AS UDT
3. END SUB
4.  
5. SUB Foo
6.     TYPE UDT
7.         AS INTEGER X, Y, Wide, High
8.     END TYPE
9. END SUB

And, even oddly enough:

Code: QB64: [Select]

1. SUB Foo
2.     DIM whatever AS UDT
3. END SUB
4.  
5. SUB Foo2 (whatever as UDT)
6.  
7. END SUB
8.  
9. TYPE UDT
10.     AS INTEGER X, Y, Wide, High
11. END TYPE

The first, in SUB foo works.  The second as a parameter of Foo2 doesn't.  And in this case our UDT is located below and independent of all our SUBS.

It's just the parameters which have this Top-to-Bottom DEFINE-style requirement, and they really shouldn't have.

[TempodiBasic]

Hi Steve
here is a very technical point....

I must thank you because in this thread I have learnt that any UDT is global with no regards to where is declared !

I never was able to imagine that! My coder mind is too near to Pascal style where first you declare then you use. Like OPTION _EXPLICIT does with variables.

With your code examples you demonstrate that in QB64 has been developed the rule that first the SUB prototype, then the local variable into SUB....

What is your point of view about this rule? And have you an alternative point of view about how to manage the UDT declaration and use?

[SMcNeill]

From what I remember, in QB45, aren't you supposed to be able to use TYPE from anywhere, and have it apply as a global template?

If so, then this parameter behavior isn't backwards compatible and needs to be corrected so that it is.

(Anyone have a copy of QB45 for testing?)

[Dav]

Hi Steve.  I just fired up my old QB4.5 (Which runs in my Windows 7, but not fullscreen)  Looks like TYPE's don't work at all inside procedures.  I didn't remember, I didn't use TYPE very much back in my QB45 days.  But when I did, it was always in the main code.

- Dav

  [ You are not allowed to view this attachment ]  

[Pete]

Correct @ Dav regarding not working in QB, but it was an added feature in QB64.

Pete

[Dav]

One thing I notice now in the QB45 IDE that's nice, and missing in the QB64 IDE, is that every menu item has a temporary help line show at the status bar for that item when the mouse is selecting it.  That could be helpful for new users.  Forgot about that.  I'm rediscovering how well made the QB45 IDE really is....

- Dav

  [ You are not allowed to view this attachment ]  

[TempodiBasic]

Yes
I can confirm that TYPE in QB45 is allowed only in the main program.

Welcome the new feature...
the complexity is matter for the  parser/compiler not for the coder.  :-)
the new rule for TYPE is that it is possible declaring an UDT anywhere in the code.
Additional rule is that this UDT structure is global.
Additional rule is that you can refer to the new UDT  BEFORE to declare it.

Good news.... this let me think to a C++ enpowerment of rules of declarations into QB64.

Well in this case I agree totally with Steve that also into parameters of SUB/FUNCTION there must be no issue to use the global UDT.
.... only more work for developers... we know that more powerment  needs more work to do.

summing news:
UDT declared anywhere? YES
UDT referred/used before declare it? YES
Good Job, it must disappear only that neo about parameters.

PS
Do you imagine how this can make evolving the programming tecnique in QB64?
I see this like a further step to be nearer to OOP style codying,

[bplus]

From what I remember of QB4.5 TYPE was only declared in declares section at top before main code. All globals at top of code.

Are you sure this works in real app, or does it just not throw error in IDE when you write this much?

Code: QB64: [Select]

1. SUB Foo
2.     TYPE UDT
3.         AS INTEGER X, Y, Wide, High
4.     END TYPE
5. END SUB
6.  
7.  

I'm cheating:
  [ You are not allowed to view this attachment ]  

But OK the next sentence "cam" be placed... hmm

But why not define at top like a normal person ;-))

[FellippeHeitor]

TYPEs are allowed everywhere in QB64 and have global scope. This allows you, for example, to ship a library that uses a certain TYPE without having to add a .BI file (although adding it to a .bi file to go at the top is good practice, in case users of your library will want to use Option _Explicit). Provided they've been declared before a Sub/Function, they can also be used as parameters to such Sub/Function.

[bplus]

Yeah Fell, I read the next line in Wiki and commented above while you were writing.

[FellippeHeitor]

Trivia: QB64 doesn't care if your TYPE is placed after/between SUB/FUNCTION blocks. Terrible practice though, so don't do it.

[bplus]

If declared in sub that sub would have to go before any UDT used as parameter in another sub is my thinking on this, a whole second I think ;-))

Does compiler ever change listings of subs, humans do and extreme caution if you move subs with UDTs around when declaring UDT in another sub.