I have a listbox that maintains a list of words that should be handled differently in an autocapitalise method. I’ll add a project that illustrates the problem I’m getting.
Click the row below the bottom of the list to add a new entry. Tab out and this gets accepted, the listbox is sorted alphabetically and Save is enabled.
If the user changes his mind he can click on the word and blank it out to delete it. Save should now disable since the list hasn’t changed. I have code in there and takes a snapshot of the listbox at the start and this is compared after each update.
Save does not disable after the delete. What the code sees is the listbox contents with an empty row where the row was deleted, Save remains enabled. Press Resume and the listbox displays with the row deleted, but Save is enabled.
Happy to acknowledge I’m doing something wrong, but I’ve tried everything I can think of, including listbox.refresh immediately. Nothing works.
It appears that the listbox is in an indeterminate state when you call enableSave at the end of CellAction. If I change the line to Timer.CallLater(0, AddressOf enableSave) it works as expected. I tested with 2025r2.1. I don’t know how far back this goes, or if it really is a bug. But I wouldn’t have expected that behavior.
The listbox is maintaining a list of words that the autocapitalise method should retain in lowercase. me.celltext(row, column).text = me.text.celltext(row, column).lowercase is what I want.
The enableSave method checks if Save should enable, it is not intended to perform the save itself. The issue I’m getting is that the way the listbox is being updated by Xojo, if a row is removed from the list, Save is always going to enable, even if the removal returns the listbox to its initial state (which means the contents haven’t changed and Save should not enable), that is because the code is not seeing the listbox contents as it actually is. That is why the first instruction in enableSave is to disable Save and then determine if it should be enabled.
This sample project is intended to illustrate the problem, not give a full overview of the save process.
The behaviour as seen has to be a bug, nobody is going to design a system that displays a blank line in the debugger. The number of rows displayed is actually correct, but it’s showing blank where the row was deleted and not the row that has shifted up to fill the gap.
The sample project I posted (is obviously a dummy project to illustrate the problem and not a live one), takes a snapshot of the listbox when the app starts up. The list is always maintained in alphabetical order. If you add a row then the size of the listbox list changes and the list is sorted alphabetically. There’s code in enableSave that detects if the sizes of the listbox and oListbox have changed and will enable save if they have. If the sizes haven’t changed then the contents are examined and if there’s a change there then save will enable. It won’t bother with that test if the sizes have changed. After the initial open oListbox is never updated.
Yes, and that is the problem. You compare contents of the listbox (sorted) wirh the contents of the array (unsorted). This does not match and therefor the Save button is enabled.
The initial state of oListbox is sorted. That is the starting state of both oListbox and the listbox. Both are sorted alphabetically. oListbox never changes after its initialisation. A change in the size of the listbox and will not match the size of oListbox and will indicate a change. If there is no change in the size then I need to check the contents. Since both lists are sorted alphabetically, the first change detected in contents is sufficient to enable save.
I don’t see why its necessary to keep sorting oListbox.
This particular window is closed after a save is executed. If i wanted to keep it open then I would refresh oListbox after the save to make it reflect the current contents of the listbox.
Thomas, you haven’t understood the issue he is seeing. His code is correct. The state of the listbox is not. After the call to me.RemoveRowAt(row) in CellAction, the Contents of the listbox are off. Ie., not in the state one would expect. That throws off the logic in enableSave. After CellAction returns, the Contents of the listbox reflect the correct state.
I don’t know if this is because we’re still in the CellAction event and this is the wrong place to be deleting a row, or if it’s a bug in the framework. I’m leaning toward bug in the framework.
Using CallLater to decouple enableSave from the event allows the listbox.Contents to be in the correct state when enableSave runs. Otherwise, the logic is sound.
