Cleaning PureBasic session history

[Piero]

"Le mieux est l'ennemi du bien". "The best is the enemy of the good"

That doesn't apply to GNU, Pizza or AppleScript

[boddhi]

That doesn't apply to GNU, Pizza or AppleScript

I wasn't referring to PB or any other language.
Simply to my tool and the fact that, sometimes, by wanting to do things better, we take the risk of doing them worse.

[boddhi]

New version:
  • Now supports multiple paths to history files
  • Code and UI improvements.

On opening, the tool tries to load the last database used and, if unsuccessful and different, tries to load the file present in '%APPDATA%\PureBasic\'. If it fails again, it will be up to the user to select a path from the drop-down list or, if none exists, to add one via the button provided.
Adding a new folder does not instantly open the database contained therein.
It is then up to the user to select it from the drop-down list.

For those of you using this tool, in order to make the UI more intuitive and the tool more user-friendly, I've made a number of changes compared to the first two versions, notably to the behavior of gadgets, keyboard shortcuts and so on. As a result, I've carried out a number of tests, but if you notice any behavioral anomalies, please let me know.

Thank you for your feedback.

[boddhi]

PS: I forgot to mention one point: Don't be surprised if switching from one database to another or closing the application takes a little time.
In fact, if you have performed operations on the database, a "VACUUM" operation is launched when the database is closed. This takes more or less time, depending on the size of the database and the number of deletions made.

[highend]

I generally like the changes. Thanks for implementing them!

One thing that bothers me, though...

As I said my history.db file is not in %APPDATA%\PureBasic so with a fresh .prefs file this will be the only "configured" path entry.
I now add the real location via the button.
I now have two configured paths.
Ofc I don't want paths in the drop-down selection that don't contain any history.db file(s) so I therefore switch back to the %APPDATA%\PureBasic entry
The app tells me that the path doesn't contain the required database file (that's fine!).
But with this path selected the delete button is now greyed out, so I can't get rid of this path here (I have to do it by editing the .prefs file directly)

So the proposed change: Do NOT grey out the delete button regardless if the selected path does or does not contain any history.db file(s). Let us delete paths from here, that's the purpose of that button

[boddhi]

Hello,

I generally like the changes. Thanks for implementing them!

You're welcome! Thank you too for your interest.

For the rest...

That's normal, that's the way it's supposed to be. The 1st line will always be '%APPDATA%PureBasic\'. Even if the path is deleted in the config file, it will automatically be added again on line 0.
And that's why the 'Remove' button is always greyed out when it points to item 0.

Why this decision? Because I think the vast majority of users will only have one history file (but maybe I'm wrong!), regardless of the number and versions of PB installed.
Which is my case, as I have the oldest version still installed, 5.73, and the most recent, 6.11b2, x86 and x64 at choice (olders are safely stored in the museum, next to the dinosaurs ). PB manages all this well in a single history file.

Is it that so annoying? Of course, I'll stay tuned.

[BarryG]

@Boddhi: Any chance your tool could do something like this? -> https://www.purebasic.fr/english/viewtopic.php?p=606903

[boddhi]

@Boddhi: Any chance your tool could do something like this? -> https://www.purebasic.fr/english/viewtopic.php?p=606903

For the moment, t's going to be difficult because

When I started coding it in 2021, I faced a problem that I couldn't solve and couldn't find any docs about.
Basically, to reduce the size of the history file, each record in the database corresponds to a part of code.
For a same file, there is the very first code which corresponds to the first compilation/save of the source and, then, the following records contain only the modifications. These ones have event and positioning codes in relation to the first original source.
The problem is that I haven't been able to understand some of these codes and thus be able to gradually follow the thread of modifications.

I can't figure out how to interpret and reposition the changes made over time in the scintilla gadget (if some kind soul
reads this message and knows, it will be most welcome!)
Deleting all events occurring before a certain date would run the risk of losing the original source code. It's whhy my tool doesn't care about dates at the moment.

I'm going to try to go back to this 2021 old code that I started precisely to manage this kind of situation and stopped due to this obstacle.

Otherwise, have you tried a "VACUUM" operation to free up unused space in the database? I don't know if PB does it when history or IDE are closed...

Code: Select all

DatabaseFile$=GetUserDirectory(#PB_Directory_ProgramData)+"PureBasic\History.db"
; or 
; DatabaseFile$="" ; <---- HERE, your history path+filename

If OpenDatabase(0,DatabaseFile$, "", "")
  If DatabaseUpdate(0,"VACUUM")
    Debug "clean ended."
  EndIf
  CloseDatabase(0)
EndIf

[highend]

Is it that so annoying?

I'm afraid, yeah...

It makes total sense to provide it as a default value on first startup!
But do you want paths that don't even exist in a drop-down field?
Or do you want them to reappear even if you've deleted their entry?

Don't get me wrong but I don't (and it doesn't matter which application that would be)

[boddhi]

But do you want paths that don't even exist in a drop-down field?

Yes, and it's even planned to.
I don't know how potential users will want to use it, so accepting folders that don't contain history files may technically be practical.
Let's imagine a user with several PCs with various installations, standard or portable, in different folders, and my tool present on a USB key that travels from PC to PC. At a given moment, on a given PC, some folders present in the config file will be considered non-existent, but will become so again on another PC, and it might then be annoying to have to restart the folder selection process. No?
If I don't allow it now, perhaps it will be requested later. So I prefer to plan it now.

Is it a good choice? I don't know. Only use will tell.
In French, we have an expression to describe this approach: "Ménager la chèvre et le choux" or how to use the middle way to try and satisfy everyone while minimizing the inconvenience for both sides. That's what I tried to do.

Or do you want them to reappear even if you've deleted their entry?

The tool, when closed, uses the contents of the drop-down list to establish the list of folders in the config file. Deleting them during use will invariably cause them to disappear from the pref file. Except the '%APPDATA%\PureBasic\' folder.

[boddhi]

New version:
A simple aesthetic addition to the folder list.
A checked mark in front of each folder if it is accessible and contains a history file:



The information is updated each time the gadget receives the focus.

[Piero]

the fact that, sometimes, by wanting to do things better, we take the risk of doing them worse.

All this pondering about pineapple on pizza is making me sick; please respect Italians