"Save time" ListBox Strategies

When you have data that have changed in a ListBox, you may want to save them (isn’t it ?).

In a current project, at first I do not flag changes. Then, I was feeling it was time to make a simple reminder.

To do that, I simply put a Boolean in the ListBox.Change Event (True) and Clear it (False) in the Save / Export / Whatever that saved the data.

Now is the time - for me - to start to implement a better and realistic way to do that (I am starting to be bored to have to dismiss the save warning in debugging…).

But, I am at loss of ideas.

What strategy do you advice for this feature ?
(Issue a “Do you want to save the changed data ?” only when needed.)

Are you editing a document or a database in your app? For a database asking the user for saving changes is optional. In a document the asking should be done as for every other document when closing. Otherwise on Cmd-S the data should be saved.

There is a flag/method for this kind of thing already.

self.contentschanged = true

This marks the window as ‘dirty’ (i.e. something the window represents may need to be saved)

Its the same thinking that you are already using, and it is still a sensible way to do it.

@Beatrix: both

@Jeff: I (probably) never saw that flag. I will explorate.

Both: thank you for your answers.

All: Happy Christmas…

I may not understand this thread, but Listbox.change is not to flag that data has changed; as far as I know Listbox.change only triggers when the Listbox.Listindex has changed (i.e. a new row has been selected) - am I wrong?

So for editing content in a Listbox (via Listbox.EditCell), I look at the Listbox.CellAction event. Then the other comments make sense, to flag that a change has been made (or the window is dirty), etc.

When a change occured, ListBox.Change is fired. I used that as a reminder to save data (at Project debug time): I always run and use a project. Adding data and not saving it is a waste of time, even at the debug process.

There is a list ListBox.Change here.

But that was not the important part of the conversation, but a simple intro. The important part was the two last lines.

(Go Figure) I even was thinking to compute the length of data in the ListBox (the number of lines, columns, characters, etc.) to flag the ListBox as dirty (have new data to be eventually saved). But even if the % is low, there still be chances (?) to loose data… (same number of lines, columns, characters, etc. but different contents !).

Thank you for participating.

Using KeyDown could be a much simpler way to mark dirty. If any non modifier key has been punched, one can assume the content of the control has been changed.

Maybe trap copy/paste/cut as well in case of menu or contextual menu modifications…

If you’re using the listbox to present a list of choices to the user where he can select one, then Change makes perfect sense to detect that the selection has changed. I would echo Beatrix. It really depends on how document-like the information is and how important it is to you that you prevent an unintended modification. In my applications, the focus is on rapid data entry, so the assumption is that the user intended to make a change (otherwise, why would he be in there in the first place?), so we do not prompt to save. We prompt on deletion, but not add/update. If the focus of the app was more on the user browsing data, then I would prompt for saving.

A bit more explanation seems to be added.

The project is like a List Manager.

You use it to search something, but you can also add things.

Typically, the project allows you to create a default list (for Books, Magazines, Comic Strips, whatever).

To be completely clear (I hope), I will take as an example the Comic Strips case:

a. the software can create the list for both daily strips (one strip every day excepted or not foe the Sunday), and list for Sunday Strips,
b. It builds

an index column(0), let a blank Column(1) for a strip title entered later manually, add a date in Column2) from data in a window, add a blank Column(3) (for end date, entered later manually) add a blank Column(4) (for the # of strips in this story, entered later manually)
c. I can add manually a Comments column (Column(5),
d. whatever I want to do.

Then, I can import data that will be merged in the above contents, and do many other things (check the start-end dates / convert dates from other formats to SQLDate for examples)

Then, the user (or me) will add strip titles / story titles in Column(1), End Date for story titles in Column(3), # of strips in this story in COlumn(4), and a tag in the Comments column: the rightmost column [of course, a column can be also added).

It actually load / appends / save text in text and csv file format. I will add an SQLite data base file that will store all data that can be saved in text and csv format + Column Align, Background colors (4), window x,y,w,h, etc.

A print (to paper / pdf) feature already exists for txt, csv, and I will add a super print feature when the data comes from a SQLite file (not coded yet, just a feature update to add…).

I am (far more than) here when I asked for your help.

Is it clearer now ?

You have been on that project for a couple years, now, right ?

Yes.

Slowly, but surely. Addin new features here and there (or is it now and then ?)

Unfortunately, it looks like a mellting pot of features…

And after a week of testings, new ideas comes to mind !

Either new feature(s), new user interface and eventually a brand new bug that never as here before (!) can appears. *

I had one yesterday: I was not able to replace ListBox1.Heading(0)… in the stand alone application (other columns were all OK !). I trashed it, build a brand new one (without changing anything in my code (but after checking if it works fine) and… OK now.

Fortunately, I do not believe in Black Cats (excepted in cartoons), but… sometimes I wonder