PureBasic Forums - English

My old PropertyGrid was based on a custom window class instead of an existing control. Looking back I think it was a mistake since there are quite some problems that an existing control would have solved in the first place. This includes several scrolling issues. Now, I want to rewrite my PropertyGrid and this time it should be based either on a ListBox, ListView or TreeView control.

So now I need answers to the following questions:

1.) Is it possible to actually hide items in a ListBox or ListView? Currently you would have to delete the items in question, temporarily save them and then re-insert them into the control to make them visible again.

2.) Is it possible to set the height of a single item? As far as I know when you set the height via #LB_SETITEMHEIGHT, #TVM_SETITEMHEIGHT and #WM_MEASUREITEM (for List-View) then this will affect the height for all items in a control.

To be honest I think you had the right idea using a custom window class. Sure it will be more work; but in some ways things would be easier believe me!

I certainly intend creating a new grid control (time allowing) using a custom class.

Being able to set the height of a single item will of course solve 1) in that you can simply hide collapsed items by setting their heights to zero and adding some code to ignore such rows when navigating between items etc. This is how the FlexCell control (ActiveX) implements a property box.

In terms of question 1); well my own propertybox control does exactly that and physically removes rows and adds them back in again as required! It works well enough especially considering that most property boxes do not hold a vast amount of rows anyhow.

Question 2)... only an ownerdrawn listbox control offers a facility for adjusting the height of individual rows, but then of course you have no subitems etc. Listboxes also come with quite a number of restrictions in terms of the number of items etc. although nothing that should upset a propertybox control.

When using a ListView control as the basis for a propertybox, one of the biggest problems was in preventing the horizontal scrollbar from flickering into view when the 'value' column was in 'auto-stretch' mode. This proved very very difficult to solve... actually I've not even released the version which finally fixes this damn issue once and for all as yet!

The point is Fluid that I think it is swings and roundabouts in terms of what is the easiest method for implementing a propertybox. I of course use EsGRID as the basis for my control (based upon a ListView control) and that thing had to go to some quite extreme lengths to solve certain issues which come as part of using the ListView in this way. Scrolling issues, redrawing issues, gridlines.... The listview control is not always comfortable with having an edit control embedded within it etc!

No, if I was starting again from scratch then it would be a custom window class for sure. Start with a clean slate. As many problems which are solved by using a ListView (for example), just as many are caused!

srod wrote:To be honest I think you had the right idea using a custom window class. Sure it will be more work; but in some ways things would be easier believe me!

Actually, after thinking it over I must agree completely. Like you said you are not bound to any restrictions that an existing control might have. You can add any nifty extra feature without to be worried about anything. In fact, I have Visual C++ 2008 installed and checked the window class they use for the PropertyGrid. I also had a look at ResEd's PropertyGrid. The both use a custom class instead of an existing control.

Well, I guess the point is that I'm just a little scared of the extra work. On the other hand I just dug out my old sources and realized that the scrolling actually already worked well. It's mostly the folding of items that still gives headaches (very big ones indeed).

srod wrote:Being able to set the height of a single item will of course solve 1) in that you can simply hide collapsed items by setting their heights to zero and adding some code to ignore such rows when navigating between items etc. This is how the FlexCell control (ActiveX) implements a property box.

Damn, that is totally amateur and dirty but kinda genius at the same time. If I think about it I just need to add an extra field in my item structure for the height. I mean I use a constant at the moment but I only need to change the height calculation so it obtains the individual height from a it's own allocated memory block.

srod wrote:In terms of question 1); well my own propertybox control does exactly that and physically removes rows and adds them back in again as required! It works well enough especially considering that most property boxes do not hold a vast amount of rows anyhow.

As you already convinced me to use a custom window class I don't have that problem anymore. I'm German after all and that "technique" is waaaay to dirty anyway.

srod wrote:When using a ListView control as the basis for a propertybox, one of the biggest problems was in preventing the horizontal scrollbar from flickering into view when the 'value' column was in 'auto-stretch' mode. This proved very very difficult to solve... actually I've not even released the version which finally fixes this damn issue once and for all as yet!

Ahh, so you are only human after all.

Sometimes I think you write these codes on a single Friday afternoon and it all works perfectly

srod wrote:No, if I was starting again from scratch then it would be a custom window class for sure. Start with a clean slate. As many problems which are solved by using a ListView (for example), just as many are caused!

Yeah, yeah ...

I think there's "no way around it", and that is good. You know I was about to go insane (seriously) while thinking about which existing control to use. Like: "If I use a ListView I have no folding, a TreeView already does that." or "If I use a ListBox the height is limited to 8-Bit values" and so on ...

Anyway, thank you very much for your precious time MASTER. Your input is very appreciated!

Or let me put it this way:

Kwaï chang caïne wrote:It's totally normal, because i'm a asshole in programming with a egg head

I was always very impressed with your propertybox control and based the look of mine totally on yours. I think your one definitely has the potential to be a far better control, so I will look forward to seeing you progress.

You are a great coder Fluid and should produce a fab control.

Speaking of KCC.... he's been quiet of late! Wonder where he has gotten to?

srod wrote:I think your one definitely has the potential to be a far better control, so I will look forward to seeing you progress.

Hmmmm ..., the reason you don't give your PropertyGrid away free is because it's based on EsGRID, right? I just started working on my again and added keyboard navigation, flicker-free display (buffered bitmap) and now almost finished Unicode support. After that I will implement the custom height for each item. Hah, it's coming along nicely. I was a complete fool to actually consider rewriting it.

Well, what I'm trying to say is that I now want to create a complete replica of the VC++ PropertyGrid. If I really get this far and it's usable I need consider not making it free but sell it for a small fee. All my API knowledge went into this baby and I really wasted quite some time to program it. So I'm not sure it will be free in the end. I hope people won't hate me for that if I charge a little. I need to pay bills too you know?

Fluid Byte wrote:Hmmmm ..., the reason you don't give your PropertyGrid away free is because it's based on EsGRID, right?

Wrong.

I give the source to the propertybox away for free as part of the Nexus package.

It just will not compile without the EsGRID source being present!

I see nothing wrong with you charging a small fee for your work; you're not forcing anyone to buy it and no one can force you to give it away for free. For those who can afford to give all of their work away for nothing; well that is well and good and very admirable, just as long as they do not expect that everyone else can afford to do likewise; I certainly cannot.

I found it easier to create a new listview control from scratch. I ran into certain limitations in one of my projects where the API listview could not provide a solution.

It's not difficult to create the actual control. The hard part is optimizing it for large data sets which I don't think is applicable for your property control.

srod wrote:It just will not compile without the EsGRID source being present!

Err.., yes, that's what I meant!

srod wrote:I see nothing wrong with you charging a small fee for your work; you're not forcing anyone to buy it and no one can force you to give it away for free. For those who can afford to give all of their work away for nothing; well that is well and good and very admirable, just as long as they do not expect that everyone else can afford to do likewise; I certainly cannot.

Sounds fair and logical to me. I mean even if you do charge money, it's on such a small scale that it's more like a donation instead of high price for an overrated product. How much you charge for EsGRID? 15 Euros? That is almost laughable considering how much work must went into this + lifetime updates.

Well, thanks again for clarfication!

One more thing ...

I just had another genius idea.

It has become a habit of mine to use a ContainerGadget as a basis for custom gadgets. If you remember my owner-draw scrollbars I released a while ago they are based on ContainerGadget()'s as well. So with a little effort it should be possible to update my PropertyGrid as well.

Why should someone do that?

- a ContainerGadget() is just a plain window not based on any existing control. It's similar to creating a window via the CreateWindowEx_() function. This means you save all the hassle to create and maintain the window via API

- It's treated as a native PB gadget. This means all commands like ResizeGadget(), HideGadget(), DisableGadget(), etc. are working without writing extra routines. One special gimmick is also FreeGadget() which I find really handy. You don't need to write an extra function for that as well since it will post a #WM_DESTROY where you can free every special allocated memory. Even the pointer to a subclass routine without producing an IMA.

- Your gadget will be compatible with native PB gadgets that only accept internal indexes / #PB_Any-Handles like SplitterGadget(), This gadget won't accept OS window handles.

- Last but not least a very major advantage in my eyes. Ever asked yourself how to create an owner-draw ListBox or ComboBox without the need to process the #WM_DRAWITEM message in the main window callback? I mean that it's all handled in an include file and not seen by the user.

You actually just need to put your owner-draw control into a ContainerGadget() and forward all incoming messages to it's child. So the user isn't forced create a window callback and it won't interfere with the callback if there is one already present.

Sorry, I just felt I need to share that knowledge since it saved me a lot of trouble in the past.

Mistrel wrote:It's not difficult to create the actual control. The hard part is optimizing it for large data sets which I don't think is applicable for your property control.

You mean mine or srod's? And exactly how big would be "large data sets"?

The original EsGRID did that (used a container for it's parent) and for the very same reason.

I abandoned it after a few versions as it proved too troublesome! Now I just subclass the parent etc.

All Nexus controls are based upon PB gadgets so that they can use the PB gadget functions etc.

Fluid Byte wrote:

Mistrel wrote:It's not difficult to create the actual control. The hard part is optimizing it for large data sets which I don't think is applicable for your property control.

You mean mine or srod's? And exactly how big would be "large data sets"?

That would be up to you. I designed mine using custom linked lists with a simple linear search. I planned for only a few hundred possible list elements on average so this simple implementation was acceptable. It did the job just fine.