Anyone know what's wrong here? (Rho knows!)

[SMcNeill]

Now, if you download the file below and extract it, you'll see that it's a simple little window system that I've been playing around with for a few hours this morning. 

IMHO this kind of approach to menu with the possibility to choose the horizontal or vertical position and moreover to gain additional submenus let me think that in the same manner you can manage other multiple objects.

In my little Menu project, Tempodi mentioned the above, and I thought I'd just waste a little time and play around with the same concept, except for a complete window style system.  Make small parts, anchor the parts to each other, end up building as complex of a system as you could ever need...

The only problem here is this glitches out -- and it glitches out in a way that completely baffles me.

The error (INVALID HANDLE) comes down on Line 158 of the main program:

Code: [Select]

    _FONT Captions(n).Font.Handle   
The only thing that has me utterly baffled here is that Captions(n).Font.Handle = 16.  I prove that just a line later with:

Code: [Select]

    FOR i = 1 TO 10
        PRINT "Captions(n).Font.Handle="; Captions(n).Font.Handle
    NEXT
A whole segment of "Captions(n).Font.Handle = 16" covers our window...

_FONT 16 is the default font in QB64, so it definitely shouldn't toss an error converting back to the natural font...

So what the heck is going on here?  Anyone with any ideas at all?

[SMcNeill]

Even more oddly:

If I PRINT Captions(n).Font.Handle, it prints 16 as a value.
If I PRINT Captions(n).Font.Handle = 16, it prints -1, telling us it's true:  the value is 16.

IF I do a IF Captions(n).Font.Handle <> 16 THEN  Captions(n).Font.Handle = 16, the glitch goes away....

The PRINT statements all agree that the value is 16.
The IF and _FONT statements doesn't think that it is...

Is this a glitch in QB64 somewhere??

[bplus]

It sounds like a Type issue, sometimes single or default will say odd things about what you think is integer.

If you get desperate enough you can try OPTION _EXPLICIT ;-))

Now I will download and check my theory ;D

[Cobalt]

You don't accidentally free that font somewhere do you? That would cause that kind of effect.  Yeah you still have its handle 'stored' in a variable but it could the actually font have been freed before you tried to use it? Just a thought, as I have done that before with images.

[SMcNeill]

You don't accidentally free that font somewhere do you? That would cause that kind of effect.  Yeah you still have its handle 'stored' in a variable but it could the actually font have been freed before you tried to use it? Just a thought, as I have done that before with images.

You can’t free _FONT 16, as it’s QB64’s built in font.  It’s always available. 

[Cobalt]

Oh yeah, not awake enough to catch myself in that one.... but I found something interesting... try putting this code right before the _font line that is erroring out.

 T& = Captions(n).Font.Handle
 _PRINTSTRING (10, 10), STR$(T&), _DISPLAY
 END

oddly enough it prints '0' not 16 for me. if N=1 then it should print 16 like your FOr\next loop.

[Petr]

Hi. Just fast tip. Try, in declarations, on row 24, this
REDIM SHARED Captions(255, 10) AS STRING 'each menu can have up to 256 entries max
replace as
REDIM SHARED Captions(255, 10) AS STRING * 256 'each menu can have up to 256 entries max
and try it again. If your problem is not caused with bug, about which i wrote...

Also in menu TYPE, please, try NAME as STRING * value, this caused bugs in my sources.

[bplus]

Hey what's captionCount supposed to be? Doesn't look like it gets a value so loop is going to get skipped.

Update: this is more likely a problem down the line, captionCount seems like a variable that should be global.

Update Definitely are missing an s in CaptionCount to match the SHARE variable!

Code: QB64: [Select]

1. DIM SHARED Windows(Integer_Max) AS Window_Type
2. DIM SHARED Captions(Integer_Max) AS Caption_Type
3. DIM SHARED WindowCount AS INTEGER, DisplayCount AS INTEGER
4. DIM SHARED CaptionsCount AS INTEGER '<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< with s
5. _DEFINE A-Z AS LONG
6.  

[Cobalt]

Id see if Vwatch couldn't show you whats going on with   Captions(n).Font.Handle   while its running cause sometimes it shows up 0 other it shows up 16, at least on my end with the Dev. Build of QB64.

[FellippeHeitor]

No type in types with vWATCH.

[RhoSigma]

I'd go with Petr's guess here,
could there be something be messed up with the implementation of variable length strings in user types introduced with QB64 v1.3?

[FellippeHeitor]

I'd go with Petr's guess here,
could there be something be messed up with the implementation of variable length strings in user types introduced with QB64 v1.3?

Does assigning the type in type variable to a normal variable retain the value and work for the _font statement? If so, Petr and Rho may have a point there.

[bplus]

That reminds me you have to initialize Type variables with 0 or empty strings(for strings also?) can't assume they already are at zero (or empty? string), they are filled in with old junk otherwise.

Update: OK already done ;D

[SMcNeill]

Does assigning the type in type variable to a normal variable retain the value and work for the _font statement? If so, Petr and Rho may have a point there.

I tried that, and still get the glitch even if everything has set length strings.  In some cases we seem to get a value of 16 (which is normal), while in other cases it gets a value of 0.

The translated C is almost indecipherable with its formatting, so if something is failing to translate properly, I can’t tell what it is at a glance.

There’s something wrong in there somewhere, but I don’t have a clue where/what it is.

[SMcNeill]

That reminds me you have to initialize Type variables with 0 or empty strings(for strings also?) can't assume they already are at zero (or empty? string), they are filled in with old junk otherwise.

Update: OK already done ;D

It does that each time the caption is created, in case we free it from use later.  (Which freeing hasn’t been added to the work-in-progress yet.)