Insertion of nodes via API doesn't work correctly in PB 4

Shardik · Post by **Shardik** » Thu Jun 08, 2006 10:06 am

This example code

NodeText.S

If OpenWindow(0, 0, 0, 250, 300, "Demo: Add Nodes to TreeGadget",  #PB_Window_SystemMenu | #PB_Window_ScreenCentered) 
  If CreateGadgetList(WindowID(0)) 
    TreeGadget(0, 10, 10, 230, 280, #PB_Tree_AlwaysShowSelection | #PB_Tree_CheckBoxes) 

    For i = 1 To 5
      NodeText = "Node " + Str(i)
;       AddGadgetItem(0, -1, NodeText, 0)
      InsertStruct.TV_INSERTSTRUCT\hParent = hItemParent 
      InsertStruct.TV_INSERTSTRUCT\hInsertAfter = #TVI_LAST
      InsertStruct.TV_INSERTSTRUCT\Item\Mask = #TVIF_TEXT 
      InsertStruct.TV_INSERTSTRUCT\Item\pszText = @NodeText
      InsertStruct.TV_INSERTSTRUCT\Item\cchTextMax = Len(NodeText)
      SendMessage_(GadgetID(0), #TVM_INSERTITEM, 0, @InsertStruct)
    Next i

    Repeat
    Until WaitWindowEvent() = #PB_Event_CloseWindow
  EndIf 
EndIf

adds 5 nodes to a tree list and works quite well in PB 3.94 but in PB 4.0 you see only black text on a black background. If you use the native PB AddGadgetItem() command instead of the API the nodes are displayed as expected even in PB 4.0. Does anyone have an explanation for it?

superadnim · Post by **superadnim** » Thu Jan 24, 2008 11:00 am

I'm having the same problem!, did you happen to find a fix?, anyone?

Thanks.

srod · Post by **srod** » Thu Jan 24, 2008 12:37 pm

I am pretty sure that it's an issue with the coloring commands added to PB 4.

For example, look at the following in which an item (item 0) is added using PB commands and item 1 is added using api. I then color item zero only - see what happens!

Code: Select all

If OpenWindow(0, 0, 0, 355, 180, "TreeGadget", #PB_Window_SystemMenu | #PB_Window_ScreenCentered) And CreateGadgetList(WindowID(0))
  TreeGadget(0, 10, 10, 160, 160)                                         ; TreeGadget standard
  TreeGadget(1, 180, 10, 160, 160, #PB_Tree_CheckBoxes|#PB_Tree_NoLines)  ; TreeGadget with Checkboxes + NoLines
	AddGadgetItem (ID, -1, "PB node!", 0, 0) ; if you want to add an image, use 
  NodeText.s = "API Node " 
	InsertStruct.TV_INSERTSTRUCT\hParent = 0
  InsertStruct\hInsertAfter = #TVI_LAST 
  InsertStruct\Item\Mask = #TVIF_TEXT 
  InsertStruct\Item\pszText = @NodeText 
  InsertStruct\Item\cchTextMax = Len(NodeText) 
  SendMessage_(GadgetID(0), #TVM_INSERTITEM, 0, @InsertStruct) 
	SetGadgetItemColor(0, 0,#PB_Gadget_BackColor,#Red)

	Repeat : Until WaitWindowEvent() = #PB_Event_CloseWindow
EndIf

I think the point is that you shouldn't use API to add items to a tree gadget created with PB commands. Use API to adjust items by all means.

However, a workaround for the original code is to simply use PB commands to add and then remove an item. Of course the tree gadget will then not behave as expected if you then continue to use PB gadget commands (such as coloring etc.) with this tree.

Code: Select all

NodeText.S 

If OpenWindow(0, 0, 0, 250, 300, "Demo: Add Nodes to TreeGadget",  #PB_Window_SystemMenu | #PB_Window_ScreenCentered) 
  If CreateGadgetList(WindowID(0)) 
    TreeGadget(0, 10, 10, 230, 280, #PB_Tree_AlwaysShowSelection | #PB_Tree_CheckBoxes) 
		AddGadgetItem (0, -1, "Normal Item "+Str(a), 0, 0) ; if you want to add an image, use 
		RemoveGadgetItem(0,0)

    For i = 1 To 5 
      NodeText = "Node " + Str(i) 
      InsertStruct.TV_INSERTSTRUCT\hParent = hItemParent 
      InsertStruct.TV_INSERTSTRUCT\hInsertAfter = #TVI_LAST 
      InsertStruct.TV_INSERTSTRUCT\Item\Mask = #TVIF_TEXT 
      InsertStruct.TV_INSERTSTRUCT\Item\pszText = @NodeText 
      InsertStruct.TV_INSERTSTRUCT\Item\cchTextMax = Len(NodeText) 
      SendMessage_(GadgetID(0), #TVM_INSERTITEM, 0, @InsertStruct) 
    Next i 

    Repeat 
    Until WaitWindowEvent() = #PB_Event_CloseWindow 
  EndIf 
EndIf

superadnim · Post by **superadnim** » Thu Jan 24, 2008 2:56 pm

Thanks srod

I find the coloring lib kinda useless to be frank with you, specially since you can't use it on buttons!

I never ever used it for anything (because I don't have the need to add funny colours on my win forms). However, if we are not calling any coloring functions, why is this behavior occurring?.

How about I create the control using win-api directly, will this still occur?

Thanks.

srod · Post by **srod** » Thu Jan 24, 2008 3:08 pm

superadnim wrote:However, if we are not calling any coloring functions, why is this behavior occurring?.

First, of the two snippets I gave above, the first is flawed because only PB uses item indexes rather than the API item handles etc. So, I'm now only 85% certain that the problem you've experienced is color related!

Still, it would make sense.

Of course only Fred or Freak can give you a definite answer here, but I would guess, if the color commands are indeed at fault, that the PB AddGadgetItem() command, when used with a tree gadget, sets up the lParam value of the associated TV_ITEM structure to point to a structure which contains PB related data on the item being added. This will include color information etc.

Now, using API to insert an item into our tree doesn't give PB a chance to set up such a structure and initialise some color information etc. Thus, your black box is simply a black background and a black foreground corresponding to color values of zero etc.

I will guess also that the first such use of AddGadgetItem() sets up some initial 'global' colors which are used in the absence of inidividual item colors etc. Hence the reason why the workaround given above works.

I will be interested to hear from Fred or Freak too see how close my 'guesses' are to the facts of the matter!

superadnim · Post by **superadnim** » Thu Jan 24, 2008 4:40 pm

If you are close enough, this means the libraries are poorly implemented IMHO!

Why depend on the color library at all to begin with?, I don't understand this... (and any elaborated explanation might fall into the "programmer's excuse" group

)

It seems to work just fine if I do 100% API so I'm guessing your guess is a good guess.

Although the constant "TVS_CHECKBOXES" is not defined?

Just in case:

Code: Select all

#TVS_CHECKBOXES 	= $0100
#TVS_TRACKSELECT 	= $0200

The 2 I needed

srod · Post by **srod** » Thu Jan 24, 2008 7:21 pm

Well, there is no color library as such. The color commands are woven into the gadget library and I think that the team have done a pretty good job here as, with Windows at least, there is no standard way of coloring the various types of gadget. That is, the method employed to color a string gadget, for example, is different to the methods employed to color an editor gadget and so on, and many of these require parent controls to be subclassed etc. It's a minefield - just the Windows way of it all!

This would have resulted in a heck of a lot of work for Fred and/or Freak.

Personally, I don't go too much for colors with my GUI's anyhow.

Of course, depending on what I am doing, I will occasionally color a gadget using pure API methods. It just depends. Other people use Gnozal's PureColor library etc.

As for the color commands being poorly implemented? Well for the reasons you cite, I would have to disagree with you completely here. In mixing PB library commands with native API, you are, if you are not very careful, asking for trouble. Take a tree gadget for example; native API deals with handles to individual items which is a pain in the arse (to put it bluntly!) Now, the PB gadget library wraps this up very nicely and offers us, instead of these esoteric handles, the use of nice indexes for each item added to the tree gadget. This, as I'm sure you'll agree, makes things a hell of a lot easier when dealing with tree gadgets. And here's my point; if you start mixing the ease of the PB gadget library (with tree gadgets) with native API, you'd better be very careful because Windows will not recognise the item indexes which PB allows us to use. You mix PB gadget commands and API tree commands and you should expect pain! Much pain!

(srod does his Mr T. impression - very badly!) And who takes the blame for any problems resulting from mixing PB gadget commands and native api in this way?

In my opinion, it is the programmer and not the PB team. Since the gadget library sits atop the native common controls library and offers ease of use as well as a lot of flexibility, you must accept that there is a trade off between this ease of use and compatibility with the API. If the two were 100% compatible, then there would be no point having a PB gadget library in the first place.

No, it is the individual programmer's job to balance a use of the gadget lib with the api and to work around the inevitable compatibility issues. Personally, and with a lot of experience with working with the Window's common controls, I can mix the PB gadget lib and API quite freely, but only through a hell of a lot of trial and error and much trawling through MSDN etc. With this kind of experience, you do get to know, in advance, where problems may occur and with this knowledge comes a real appreciation of just how good the PB gadget library is.

END OF RANT!

superadnim · Post by **superadnim** » Fri Jan 25, 2008 7:59 pm

Nice reading.

In my case, going 100% API for my tree-gadgets is not bad at all. It allows me to learn more about the API, whereas using the PB library I might get a wrong idea of how things really work.

I promise I won't mix them again until I get a black belt

srod · Post by **srod** » Fri Jan 25, 2008 10:30 pm

superadnim wrote:I promise I won't mix them again until I get a black belt