Resource inside Namespace

I have a module that contains a few classes and interface (Thanks Norm and Karen :slight_smile: )
But it doesn’t seem possible to include a graphic resource (ie. PNG file) INSIDE the module and make it PRIVATE to said classes?

No
And I’ll be darned if I can even recall why this is the case
Cant even find an FR to make it possible

[quote=175648:@Norman Palardy]No
And I’ll be darned if I can even recall why this is the case
Cant even find an FR to make it possible[/quote]

It logically should be possible, but as it was not possible from when I came in (RB3), it never occurred to me to even file a feature request!

  • Karen

Well, if it is a PNG (or any picture format, really) you can encode Picture.getData in base 64, store it in a constant, and then decode and recreate the picture when it is needed.

For those interested… what I am creating (as I need it for another project)… is a “light weight” TREEVIEW… and before you all start… Yes, I know HIERARCHICAL Listbox, or Einhugur… but I found big issues with both those … One, handling multiple levels of branches with Listbox, or customizing the Expand/Collapse indicators, or drawing “tree lines” was a royal pain. The Plugin version was a) a plugin :slight_smile: and b) $109.00! and really seemed convoluted to use (perhaps it was the various extra features?)

Anyways… Mine is not a plugin… 100% XOJO code… Consists of a Public Class, a Private Class and a PNG (hence the above question)

Everything is based on keys based on Parent/Child relationships with a single ADD method… Branches can be added in any order, and the control internally deals with the links. So far it looks pretty good, It allows for OSX, Windows or “Standard” (+/-) style expand/collapse indicators (in 3 sizes 16,24 and 32px) , each node can also have a custom icon (I’m toying with adding checkbox, but not sure yet)…

So in my mind …
Pros…

  • 100% XOJO code (no declares, no plugins)
  • won’t cost $109.00
  • isn’t a plugin
  • easier to use than HIERARCHICAL Listbox (even though the container control IS a listbox)
  • custom user icons
  • user can change expand/collapse icons if required (just edit supplied PNG file)
  • automaticaly calculates and draws connecting lines (which can be turned off)
  • margin (from left edge of control to left edge of tree) is customizable
  • indent (from left edge of tree to branch) is customizable

Cons…

  • is just a TREEVIEW, Einhugur does have more “features”, but not many that I can see

When I get the “pretty” part done, I’ll post a picture

[quote=175653:@Dave S]For those interested… what I am creating (as I need it for another project)… is a “light weight” TREEVIEW… and before you all start… Yes, I know HIERARCHICAL Listbox, or Einhugur… but I found big issues with both those … One, handling multiple levels of branches with Listbox, or customizing the Expand/Collapse indicators, or drawing “tree lines” was a royal pain. The Plugin version was a) a plugin :slight_smile: and b) $109.00! and really seemed convoluted to use (perhaps it was the various extra features?)

[/quote]

Yes drawing lines is a pain in the Xojo hierarchical listbox… But you only have do it once, assuming you create a subclass to do it.

My Mergeable Cell Listbox subclass does that, and in the past Alex Restrepo had an open source listbox subclass that drew connecting lines (though I don’t know if it is still available). Both are 100% Xojo/RB code.

It’s true you have no control over the look (or placement) of the disclosure widget with the Xojo listbox.

But while i wish I had control over placement (Like where it was in vertically merged cells), I don’t know why one would want to use anything but the platform standard widget.

What do you see as the issue with that for the Xojo listbox?

For the Xojo listbox you have to have an underlying tree data structure of some sort as teh listbox does not have one built in… But I think that is a good thing. That tree repesentation needs to be flexible as different situations need different solutions… It can be anything from node classes with arrays to getting the tree DB tables using SQL on the fly to get the children. (I’ve used both approaches)

I have also written code a few times to be able to drop new children (or branches) to add then to a node, or to use drag and drop to reorder whole branches in a tree. (that is not in my listbox class - I never tried to generalize that)

  • Karen

I dont recall if I looked into this once upon a time or not nor what I found

Filing a request is not a bad thing since I cant think of any reason it should not be possible off the top of my head

Well for me those were the problems I percieved, and those are the problems that this controls solves (for me)

Now that you mention it, I bumped into the convoluted hierarchical listbox last year, and after encountering issues right and left, and the lack of flexibility, I finally devised my own.

If your class had been around, I would probably have used it :slight_smile:

[quote=175648:@Norman Palardy]No
And I’ll be darned if I can even recall why this is the case
Cant even find an FR to make it possible[/quote]

38680 - Please make it possible to have resources inside a module
<https://xojo.com/issue/38680>

[quote=175684:@Michel Bujardet]Now that you mention it, I bumped into the convoluted hierarchical listbox last year, and after encountering issues right and left, and the lack of flexibility, I finally devised my own.

[/quote]

I am really curious about why people think the Xojo Listbox (hierarchical or otherwise) is inflexible.

I find it extremely flexible outside of all rows having to be the same height and (for a listbox with a LOT of rows) that it holds all the data internally (which is the issue the Data-on-Demand listbox solves)

Not sure also what is convoluted about the hierarchical support. To me it seems straightforward . Granted it does not directly support creating or managing the tree data structure, but as I said I see that as positive a it does not force a one size fits all approach to managing tree structures.

  • Karen

I too think the built-in hierarchical listbox is working well. I have made a subclass and I have implemented the following to hold the data:

[code]Event CollapseRow(row As Integer)
Dim children() As Dictionary = RowTag(row)
For i As Integer = 0 To children.Ubound
children(i) = RowTag(row + 1 + i)
RowTag(row + 1 + i) = Nil
Next
RaiseEvent CollapseRow(row)
End

Event ExpandRow(row As Integer)
Dim children() As Dictionary = RowTag(row)
For i As Integer = 0 To children.Ubound
AddRow(children(i).Value(“Text”).StringValue)
RowTag(LastIndex) = children(i)
Next
RaiseEvent ExpandRow(row)
End[/code]
One could also implemented this in a way so that RowTag can be used from the application, which is currently not the case with the code above.

And key pressed are handled here to make navigation and collapsing/expanding easier:

[code]Event KeyDown(key As String) As Boolean
If RaiseEvent KeyDown(key) Then
Return True
End

Select Case key
Case KeyLeft
If Expanded(ListIndex) And RowTag(ListIndex).IsArray Then
Expanded(ListIndex) = False
Return True
Else
For i As Integer = ListIndex - 1 DownTo 0
If RowTag(i).IsArray Then
ListIndex = i
Return True
End
Next
End
Case KeyRight
If RowTag(ListIndex).IsArray Then
If Expanded(ListIndex) = False Then
Expanded(ListIndex) = True
Else
ListIndex = ListIndex + 1
End
Return True
End
End

Return False
End[/code]

[quote=175701:@Karen Atkocius]I am really curious about why people think the Xojo Listbox (hierarchical or otherwise) is inflexible.

I find it extremely flexible outside of all rows having to be the same height and (for a listbox with a LOT of rows) that it holds all the data internally (which is the issue the Data-on-Demand listbox solves)

Not sure also what is convoluted about the hierarchical support. To me it seems straightforward . Granted it does not directly support creating or managing the tree data structure, but as I said I see that as positive a it does not force a one size fits all approach to managing tree structures.[/quote]

Karen, if I may, you are the specialist of listboxes. I am not. Maybe what is natural to you come from years of familiarity with that control. Sometimes it takes more energy to deal with an existing control than to design one’s own. That is what I did, I am happy with the result, and I do not think I will ever look at hierarchical Listbox again.

While the standard listbox gives one the option to do as one needs to do, Just look at the code the Eli posted and compare that to

[code]
treeview1.add(parent,child,description,icon)

treeview1.expandnode(parent)

treeview1.collapsenode(parent)

[code]

The only “overhead” from the developers point of view, is making sure the “parent” and “child” keys are unique.

Now that being said… do we really need to continue this p*ssing contest?
I don’t like dealing with hierachical listboxes in their standard incarnation, nor does it seem that Michel does, but that is not to say that we are wrong for having such an opinion, nor that the efforts that I am making are a waste of time (my time to waste), nor will it perhaps be useful to others of a like viewpoint. Regardless… the control will work for the project it is intended and to me that is all the really matters.

[quote=175707:@Dave S]While the standard listbox gives one the option to do as one needs to do, Just look at the code the Eli posted and compare that to
[/quote]

Well that is not exactly fair. That depends how on wraps the functionality of the standard listbox rather than it being inflexible. Your API is handing lot of code under teh hood that could be more exposed. BTW IIRC Alex Restrepo’s Treeview listbox subclass used a similar API to to what you show above)

It’s not about that… or touting my abilities (heck I am no where near in the same league you are in and know it!!!)

Over the years I have heard more than a few people say the Xojo listbox is inflexible and want it replaced with something else. I don’t want to see that happen.

My point simply is that It really is an amazingly flexible control, that once one learns/understand the API, can be made to do a LOT of things XPlatform with a lot less work than starting from scratch, particularly for those that are not in your league.

I just don’t want people to be scared away from learning it (or Xojo inc to be dissuaded from maintaining/upgrading it!!!). I want to encourage others to use it to it’s full capabilities.

  • Karen

gee… every single point you made applies to SO many other tools and controls (MBS anyone?)

I am not advocating the removal/replacement of Listbox, it has its uses, but has its limitations, my TreeView has its uses, and its own limitations.

And as to how flexible the listbox is, I agree it is VERY flexible, but in MY OPINION, a royal PITA to use for anything other than simple “table” applications… Reality does not exist, only ones perception, and this is MY perception. And at somepoint it was also the perception of Alex, and Einghur or they won’t have done something similar in the past

with that I am done with this conversation…

What’s convoluted is that you have to track any changes you make to the data if a node is collapsed and then the user expands it. It’s not difficult, but it is certainly not a ‘load and forget’ sort of deal. For that one issue alone I tend to like the Einhugur TreeView because the nodes are persistent and once you load it you never have to worry about them again.

The Einhugur TreeView isn’t as flexible for some things but we’ve used it on many projects and it’s worked well. I guess it all depends on what you want to use it for - just like the built-in hierarchical listbox.