Unexpected codes generated for ListBox when deleted, 'Add Scrollbar?' unselected

[knyipab]

I found weird behavior of code generation when it comes to ListBox. Here are the two cases and how to reproduce the bug.

Delete the ListBox

1. New a project and add a ListBox
2. Generate code
3. Delete the ListBox and then generate code again (bool CbSlidePos are still there and E_LISTSCROLL1 gives undefined error)

Unselect 'Add Scrollbar?'

1. New a project and add a ListBox
2. Generate code gives
3. Unselect 'Add Scrollbar' and generate code. The scroll code are still there, and it gives two //<Slider Enums !End!>!

//<Slider Enums !Start!>
//<Slider Enums !End!>
    case E_LISTSCROLL1:
      // Fetch the slider position
      nVal = gslc_ElemXSliderGetPos(pGui,m_pListSlider1);
      //TODO- Replace with slider handling code
      break;

//<Slider Enums !End!>

4. Select 'Add Scrollbar' again and generate code. There are two case E_LISTSCROLL1:.

[Pconti31]

assigned bug 124. Thanks for the info and I will investigate further.
in the future if you could provide a zip file of your project folder it would speed up my testing.
Also the build version of the GUIsliceBuilder and platform you are targeting.
Paul--

[Pconti31]

I identified the problem and it applies to most of our callbacks if you delete the full set of say any one UI type like buttons, sliders, spinners and or listboxes. Since the set is empty the builder wasn't examining any case 'ENUM' statements in the callbacks to see if some needed to be deleted. This will be fixed in version 0.13.b010 of the builder. I'll spin a build next weekend.

NOTE: if you delete a full set of some UI element that requires a callback the builder as designed cannot remove the callback. It will now however generate correct code that removes the extra case statements.
Paul--

[Pconti31]

fixed in release 0.13.b010

[trevorsmedley]

This issue (or at least something closely related) seems to have reappeared in 0.16.b011, at least with respect to spinners. When all spinners are deleted, the following callback remains:

// Spinner Input Ready callback
bool CbSpinner(void* pvGui, void *pvElemRef, int16_t nState, void* pvData)
{
  gslc_tsGui*     pGui = (gslc_tsGui*)pvGui;
  gslc_tsElemRef* pElemRef = (gslc_tsElemRef*)(pvElemRef);
  gslc_tsElem*    pElem = gslc_GetElemFromRef(pGui,pElemRef);

  // NOTE: pvData is NULL
  if (nState == XSPINNER_CB_STATE_UPDATE) {
    // From the element's ID we can determine which input field is ready.
    switch (pElem->nId) {
//<Spinner Enums !Start!>

//<Spinner Enums !End!>
      default:
        break;
    }
  }
}

This causes the following error, because the file "elem/XSpinner.h" is no longer included:

error: 'XSPINNER_CB_STATE_UPDATE' was not declared in this scope
if (nState == XSPINNER_CB_STATE_UPDATE) {

[Pconti31]

@trevorsmedley You should have noticed my NOTE I made on Dec 30, 2019.
NOTE: if you delete a full set of some UI element that requires a callback the builder as designed cannot remove the callback. It will now however generate correct code that removes the extra case statements.

The Builder was a quick and dirty program I wrote for my own use a few years ago. I later realized other people might find it useful even given its limitations. I have worked to expand its functionality over time as Calvin @ImpulseAdventure has added new features. However, at its core the current design has some major holes can't be fixed without breaking existing projects or even worst without a major redesign of the code base.

So, in some cases, the simple solution is for users to hand edit the code. In your case I would delete
the bool CbSpinner callback completely and replace the code with the spinner callback tag so that if you add a spinner in the future it will be handled correctly.
The tag would be:

//<Spinner Callback !Start!>
//<Spinner Callback !End!>

Anyone that wants to address its limits is welcome to submit pull requests or contact me for consultations for how to make improvements.