Hi, I've placed an iconView control in my form, and now want to programatically add some icons ~
But the following code isn't doing anything (Click event isn't where the code will end up, but I wanted to test icon-additions first);
Nothing is appearing in my iconView.  Do I have to instantiate anything beforehand?
All help/comments gratefully received…
C.

Try changing the Click to MouseDown

Thanks Cogier, that's working great now. My next question…

How do I catch an Enter event for, say, the first icon added to my iconView?  
I know I'll need to code an  _Enter() event, but what is the Subroutine's name/syntax for a programatically added object, ie:


Many thanks again.
C.

It's not possible with iconview.

I just examined the IconView code and the icons are not actually controls.
comp/src/gb.gui.base/.src/IconView/IconView.class · master · Gambas / gambas · GitLab

It is a ScrollView that uses the _Draw() event to draw the icons.

As the icons are not actually controls that inherit Control.class they do not have a hover event.

But after saying that I should clarify, it's not possible by default ,

but anything is possible with gambas

Attached is a workaround example.

I create a file called IconView.class in my .src and use it to add an IconEnter and IconLeave event.  both events show the icon key

I create an "Observer" to monitor the IconView events and react to the MouseMove event.

caveats: it sets the internal cursor .Item as it moves.

Note: things  get a little more advanced than "beginner" level when you want to do things that are not by design. but learning how to override classes and controls is very useful for getting things how you want it to be

BruceSteers said

But after saying that I should clarify, it's not possible by default ,

anything is possible with gambas

Note: things  get a little more advanced than "beginner" level when you want to do things that are not by design. but learning how to override classes and controls is very useful for getting things how you want it to be

I was bored so I expanded the code a bit to demonstrate how easy it is to modify a gambas control to suit your own desires.

It's the same IconView mod but has a couple of other additions to make it work a bit like a file browser

This IconView has the following properties added..
IconView.Dir or IconView.Path , set and load the current directory
IconView.ShowHidden , show hidden files
IconView.DirsFirst , sort folders above files


also staying with the original question hovering over an icon makes the icon text green and sets the tooltip to the icons full path, then restores on the IconLeave event

Ps. to use it just copy the IconView.class file to your projects .src folder

Enjoy

Hi Bruce,
Thanks, that a very elegant solution to my problem - effectively just 9 lines of code transforms a not very useful control!  :shock:
Just a couple of questions…
Can you explain the relationship between the new class Name - 'IconView' - and the Export statement in the code?  The documentation for 'Export' isn't very clear:  "means that this class will be visible from the outside when making a component."…
How have we made a component in this code? - does Export statement include 'Inherits [IconView] class' by default?  

Also, if I want to trap a Click event on an added icon in the IconView1, will I have to create another Observer, or can I use that's already instantiated?

Many thanks for both v.useful examples; the second has shown me how to use richText'ing too, which is a bonus!   
chrisR.

Sure , It's not a "new" class name it's a duplicate of an existing one.

It is what is called Automatic inheritance.

Gambas already has IconView.class , that is the IconView control code.

By making a class with the same IconView.class name it inherits IconView automatically.

Any of it's shared commands (like Public Sub _new() ) will be referenced before the normal IconView is.

Export makes the properties of a class visible . if i do not use Export then all the inherited parent IconView properties will also be hidden.

The Click event for your IconView controls does not change from normal,no need to do anything, the IconView will do all that a normal iconview does plus anything you added to the new class of the same name.

I wrote a quick "how to" about automatic inheritance Gambas One - Gambas ONE

Thanks Bruce, very helpful info.
Coming from an ancient background in non-object programming (Fortran!) I'm still coming to terms with a whole load of additional concepts :?

One thing I didn't quite understand in your page about Automatic Inheritance:


If we've gone to the trouble of creating an overriding 'Enabled' property, then why set and return the 'Super'.Enabled property, rather than our newly created one?  How do we know, programatically, which has been set with a value and which hasn't, so we can read it back again?
Maybe an example usage would help me understand the underlying logic  :roll:

Many thanks,
C.

Having the "Property" called Enabled is not an actual variable to set.
The Enabled property will just use Enabled_Read and Enabled_Write methods (if they exist)

In the Read or Write methods we would normally reference a variable for example $bEnabled As Boolean

But our override does not need to do that as it just uses the Read/Write methods to get/set the Enabled property of the inherited class "Super"

The Enabled property of the Super (Timer.class) will enable or disable the timer.
The overridden Enabled property in my class does not really have any other code to do anything except trigger the new "Stopped" event.

It is not so much intended to be an override, more an interception. So in the override I have to use Super.Enabled to do what it is supposed to do, enable or disable the timer.

when i set $hMyTimer.Enabled = False  , my Timer.class code has an Enabled property so that will be referenced and not the Super.Enabled. but i want the Super.Enabled to set, and also have my code to trigger a Stopped event if the value is false.

I hope that makes sense.  the auto-inheritance is not a complete class, when overriding Properties/Methods that exist the override becomes the used function,
to access the real parent property/function we must use Super

It's a case of try it out and see for yourself now
you will find some things not so easy to override, it depends what it is.
It's awesome though the way we can access and modify the components to our own needs

 A couple of extra tips.
Don't use "Me." in accessor methods for inherited properties. That will just generate a stack overflow as the accessor  is just called over and over again.
"Super" is also useful to call public methods exposed by the parent class.

An explanation of sorts.
When you use such auto-inheritance what gets "done" is that the symbol table is augmented with the local class public symbols. So we need a way to tell the runtime "Dont use the lowest occurrence of that symbol, use the one in the parent class." Hence "Super".