Dirty trick, store addtional boolean value in ListIconGadget

[infratec]

Hi,

at the moment I'm writing a database application with many ListIconGadgets.
As ItemData I store always the ID of the record.

Suddenly I had the need to store an additional boolean value which should not be shown in the ListIconGadget.
Ok, I can use the ItemData to store a pointer to a struct.
But that was to much effort.

After a bit of thinking and testing, it results in:

Code: Select all

OpenWindow(0, 0, 0, 300, 300, "Dirty Trick", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)

ListIconGadget(0, 10, 10, 210, 280, "Dummy", 200)
For i = 0 To 9
  AddGadgetItem(0, i, "Dummy " + Str(i + 1))
  SetGadgetItemData(0, i, i)
  If (i + 1) % 2
    SetGadgetItemColor(0, i, #PB_Gadget_FrontColor, 0)
  EndIf
Next i

ListIconGadget(1, 230, 10, 60, 100, "Values", 50)

Exit = #False
Repeat
  Event = WaitWindowEvent()
  Select Event
    Case #PB_Event_Gadget
      If EventType() = #PB_EventType_Change
        ClearGadgetItems(1)
        AddGadgetItem(1, -1, Str(GetGadgetItemData(0, GetGadgetState(0))))
        If GetGadgetItemColor(0, GetGadgetState(0), #PB_Gadget_FrontColor) = 0
          AddGadgetItem(1, -1, "Odd")
        Else
          AddGadgetItem(1, -1, "Even")
        EndIf
      EndIf
    Case #PB_Event_CloseWindow : Exit = #True
  EndSelect
Until Exit

I use the FrontColor to store the boolean value
Normally this value is -1.

Hm, I don't think that someone sees the difference from $010101 to $000000.
So you can store 3 additional boolean values

Bernd

[akj]

Interesting idea, but ...

If you ever need to edit your program in a few months time, you are likely to spend ages wondering why you were changing the gadget's front colour and even longer wondering why your were doing (i+1) % 2 in the code snippet

Code: Select all

  If (i + 1) % 2
    SetGadgetItemColor(0, i, #PB_Gadget_FrontColor, 0)
  EndIf

I strongly suggest that at the very least your code includes full comments explaining the 'dirty trick', to save yourself future headaches.

Your idea reminds me of my early programming days when I often used a variable for other/more than it's obvious function. For example I might use the variable 'age' to not only store a persons age but also (say) thereir retirement status by making the value negative if they were retired. This would work well until the program requirement changed so it was necessary to also know their degree of retirement, for example, if they were semi-retired. Then it was necessary to use two (or more) variables 'age' and 'retirement_status' which is what I should have done in the first place.
In my opinion, every variable, object and property should be used 'exactly as stated on the tin'.