# Visual Basic > Visual Basic 6 and Earlier >  [RESOLVED] Cairo, Inventory Screen Woes

## -Corso->

https://www.dropbox.com/s/cjln2hvej0...cking.jpg?dl=0
Hi all, probably YAOQ, (Yet Another Olaf Question).

See image at link above. 

The Inventory Screen has 2 children, a decorative border and the Item Display (Printing Area).
It can print all the inventory items very well. But, I now need to click on said items to show data, or drop the item from inventory. 

If the MouseMove was trapped at the Inventory Master Screen (Class Inventory), all would be good. BUT, after checking, the MouseMove event is only grabbed from the Decorative Snake Border (Top). {Unless you leave that area.} 

The problem is, the Decorative Border is re-used so it doesnt know that its a child of the Inventory Screen. What I mean to say, I dont know the code for parsing the MouseX&Y up the chain to the Inventory Screen.

I tested W.Root. Parent etc. But I have zero idea. It is just a command or something larger?

How does one push the Mouse X&Y up to the parent Class? So that when I move the mouse around, I can then examine it via its true parent. 

Thanks!

----------


## Schmidt

> The Inventory Screen has 2 children, a decorative border and the Item Display (Printing Area).


IMO one way to bring more clarity (to you and all readers of future problems) is,
when you'd follow the "naming-suggestions" I've tried to introduce in my demos.

Other than in "normal VB6-GUIs" we cannot determine the "type" of a GUI-element by its file-ending
(when using Widgets).

In normal VB6 we'd have e.g. (expressed hierarchically)
Overlay.*frm* (the "Root-Container", TopLevel-Window, hWnd-based)
-- Inventory.*ctl * (a Control-Container, Child of Overlay)
---- Display.*ctl* (another Control-Container with a scrollable Item-List and a few Buttons, Child of Inventory)
---- SnakeBorder.*ctl* (another Control, which acts like a "plain Image-Background", Child of Inventory)

Same thing, expressed in "Cairo-Widget-Speak" ...
(and now we have to use prefixes, because everything has the File-Ending *.cls)
*cf*Overlay.cls (the "Root-Container", TopLevel-Window, hWnd-based, derived from an internal: Form As cWidgetForm)
-- *cw*Inventory.cls (a Widget-Container, Child of cfOverlay, derived from an internal: W As cWidgetBase)
---- *cw*Display.cls (another Widget-Container with a scrollable Item-List and a few Buttons)
---- *cw*SnakeBorder.cls (another Widget, which acts like a "plain Image-Background")

Such a "properly prefixed and indented Hierarchy-List" would free you from posting any ScreenShots in the future.

Now wait... because there's still something wrong in the above Widget-Hierarchy-Listing...
meaning, that it doesn't take into account, that:
- VB-Classes are meant as "generic-templates"
- which allow to create slightly differently behaving instances of said templates

Take for example the cwCont9.cls I've posted in earlier threads.
It acted as a *generic* container-template, which allows to use it multiple times in different instances,
with "freely choosable Border-PNGs" (set on each instance differently via MyInstance.Widget.ImageKey).

With that generic Container-Widget-Class, your Hierarchy-Listing could (or schould) look more like this:
fOverlay As cfOverlay (the "Root-Container", TopLevel-Window, hWnd-based, derived from an internal: Form As cWidgetForm)
-- *cnt*Inventory As *cwCont9* (a Widget-Container-Instance, with e.g. ...Widget.ImageKey = "PlainBorder.png")
---- *cnt*ItemList As *cwCont9* (another Widget-Container-Instance, with e.g. ...Widget.ImageKey = "SnakeBorder.png")
------ *lst*Items As *cwVList* (List-Widget-Instance of type cwVList, added as a Child to cntItemList )
------ *btn*AddItem As *cwButton* (Button-Widget, added as another Child to cntItemList )
------ *btn*RemoveItem As *cwButton* (Button-Widget, added as another Child to cntItemList )

Ok, so the above is finally a properly named (and Class-typed) Widget-Hierarchy:
- which will not have any Mouse-Event-Problems
- and would not require "guessing from ScreenShots", how you structured your GUI

As for the cwCont9.cls (which even supported "Mouse-based-resizing") -
you could modify it appropriately (in case you prefer to pass 5 or 6 or 9 "Borderfragment-PNGs"),
with relatively low efforts - by just putting a comma-separated List into the ...Widget.ImageKey
(which you could then easily "split into an array" in the W_Paint-Event).

E.g. as:
- Widget.ImageKey = "SnakeBorder_TopL,SnakeBorder_TopM,SnakeBorder_TopR,... a.s.o."
- or alternatively assume (in the Widgets Paint-Event), that the ImakeKey in this case is only a prefix:
---- W.ImageKey = "SnakeBorder"
---- and in the Paint-Event you derive the real Cairo-ImageListKeys by appending "_TopL", "_TopR" yourself.

This way your own cwContGenericBorder.cls could be implemented in a way,
which allows "dynamic swapping between multiple pre-defined Border-Png-Fragments"
(depending on, which ImageKey you gave it after instantiation).

HTH

Olaf

----------


## -Corso->

https://www.dropbox.com/s/471j03op3n...Sheet.jpg?dl=0
Hi Olaf,
Here's a picture of the current working Inventory Section of the Master Character Sheet.
I placed items onto an indented grid instead of a list form. I chose this current setup as it had the most user/visual appeal. It makes sorting and filtering look good too (they work too).

Some users prefer lists (I don't at all). But, I'll implement your list array presentation later, as it will be good to have as another option, as half the audience prefer that method. But at the moment, I need to 'wow' wherever and whenever I can.

Curerntly, IO (Invisible Overlay) is the general overlay. Io.Form
Under that we have the Class_Character_Main_Window.cls (Which is the big blue window) and a bunch of others classes are connected, the inventory page, the tile cursor, mini popup item panel, character speech bubble and so on. 
The Inventory, Class_Inventory_Image_List.cls is the content 'inside' the big blue window. Buttons (from a home made button class), Mini Snake Border ((self-adjusting)Class_Snake_Mini_Border.cls), and the drawing of the items has now gone back to a standard image (cwImage) <-Surface copy to. ({I was testing a new underlay flat widget class prior}). 

I didn't use 'buttons' as the items as there might end up being hundreds of them on screen at once. So many controls and I've heard VB borks.

Oh, and everything, literally everything is named 'W' except the overlay form.

I might retry the underlay form again, but I'll place it Z-order above everything else. For some reason, it never worked, as in, it wouldn't display the item images last time unless it was below the snake border class.   :Confused:   :Confused:   :Confused:    If I use this method, it will end up being a dedicated inventory selection, Mouse_XY panel. And I can live with that.

Also, this inventory screen is a fixed size for the moment, only the mini snake border resizes. I'm doing this as I need to figure out 'what' gets placed and where. As everything is in flux, even this design may get a total overhaul (except for it's sections).

----------


## -Corso->

https://www.dropbox.com/s/nlg200rn56...rking.jpg?dl=0
Annnnd it's working. Picture above.

Having the dedicated Inventory Panel Widget Screen does the trick. Looks like I was clearing the wrong surface for a while too. Goddammit. Now we have Mouse X and Y for panel placement/interrogation. -> Now onto the ability to Right Click, Drop and Item. Closer and closer......

----------


## -Corso->

https://www.dropbox.com/s/4fjw8irb2t...Items.jpg?dl=0
Annnnd now we have organized drops from the Inventory. Yay! Time for a break.
And,
Merry Monstergirl Christmas Everyone!   :big yellow:

----------

