Cleaning PureBasic session history

[boddhi]

Unpretentious little tool to help purge PureBasic session history.




If like me, you keep all the history (no purging), at some point, it may be interesting to do a little cleaning while still keeping what you want.

This tool lists the source codes of existing, non-existent files, unsaved codes and empty sessions and allows you to delete those you have selected.
It is mainly useful for non-existent files (deleted or moved) and unsaved code (e.g. testing sources from PB forums).

Possibility to manage several access path to the history files.
4 languages ​​are supported: French, English, German and Spanish (If you notice any translation errors, do not hesitate to let me know or if you want a localized version, tell me, there are very only few terms to translate).

Download

[highend]

The only thing that it does here is creating a .prefs file. No window, nothing.

How does it try to detect the History.db file?
I'm using a portable version of PB, maybe that's the issue (but in this case it should at least bring a message requester stating that it can't run because of reason <x>...)

And yes, my session history contains entries

[boddhi]

The default path is %APPDATA%\PureBasic\

I didn't think to include the case of a portable installation, as this is a very very rare specific case.
What is the folder structure of your installation since PureBasic folder?

[Demivec]

I didn't think to include the case of a portable installation, as this is a very very rare specific case.

Portable installations is the usual method for me. I run different versions at the same time as well. As a consequence I have many history sessions, one for every possible PB version (in windows) as well as a single one for the latest beta version. So that's about 60 separate history files being maintained (since version 5.10). As you can see, instead of a very very rare specific case it instead makes it a very very common case for me.

The directory structure is maintained, just not the installation path. If it was possible to specify the installation directory that might be a workable solution. If it was also possible to have a list maintained that could be selected from, like the way compilers are added in the PureBasic IDE, and to be able to select from that list it would make it very useful.

[boddhi]

New version: Possibility to select a folder other than the one provided by default by PureBasic (%APPDATA%\PureBasic\). Particularly useful for those using portable versions of PB.

[boddhi]

If it was possible to specify the installation directory that might be a workable solution. If it was also possible to have a list maintained that could be selected from, like the way compilers are added in the PureBasic IDE, and to be able to select from that list it would make it very useful.

I coded an alternative to select a folder other than the default one before seeing your message.

I must confess that I'm an ordinary user and usually only use one or two versions at a time.
At the moment, I'm using either 6.04 or 6.10. The first if it doesn't use the new features of 6.10, for reasons of executable size.

However, I'll take your request into consideration

[Demivec]

I appreciate it very much. I know I'm not the only one but most individuals use 2 or three versions at the most.

When converting old code the process can take long enough to complete that one or more new PureBasic versions are released. There is a lot of old code out there and it is maintained for different releases of PureBasic.

[BarryG]

I didn't think to include the case of a portable installation, as this is a very very rare specific case.

Rare? Being portable is one of PureBasic's major features.

[boddhi]

Rare? Being portable is one of PureBasic's major features.

Ok, well, MEA CULPA EST, according to your comments, it seems that it's more common than I thought and said something really stupid!

I've been coding with PB for 20 years and have never needed a portable version.
But indeed, in a professional environment, I can understand that this might be necessary.
And the few times I needed it professionally, the development was done at home...

[boddhi]

I appreciate it very much. I know I'm not the only one but most individuals use 2 or three versions at the most.

When converting old code the process can take long enough to complete that one or more new PureBasic versions are released. There is a lot of old code out there and it is maintained for different releases of PureBasic.

Just to be clear, my tool does not care about the PB versions with which the sources were coded, nor the dates...

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.

This is why my tool only focuses on determining sources through existing, non-existent files or unsaved sources and deletes ALL records (original and modifications) of files. It's its limit (and probably not the only one ) !

For the moment, the only thing I can offer is to be able to access other history files than the one present by default in the user folder.

[BarryG]

@boddi: It wasn't stupid what you said; just unusual. I've also used PureBasic for over 20 years and only officially installed it once. Ever since then when I've needed it on a new PC or VM, I've just copied its folder over because it's portable.

[highend]

Can you please store the last used path in the .prefs file please?
So that we don't need to navigate to the history.db folder each time we start the tool

Additionally this would be the cherry on top (for those that use multiple (portable) installations):
Add a string field to the GUI with a dropdown (that contains the last <x> paths you've opened) together with a button that opens the PathRequester() to select a folder.

Then you can switch between multiple .db files quickly...

[boddhi]

Ever since then when I've needed it on a new PC or VM, I've just copied its folder over because it's portable.

I did this for many years but since, I don't know which version, I got issue due to the registry values created during installations.
I haven't really looked into the details of why and how (and may have missed a step or a piece of information) but, now, in this case, I install from the official PB installer and copy the config file where it belongs (and the history file if necessary). I admit, however, that this may not be the best or simplest solution .

Add a string field to the GUI with a dropdown (that contains the last <x> paths you've opened) together with a button that opens the PathRequester() to select a folder.
Then you can switch between multiple .db files quickly...

That's the option I'm working on right now.

 

Can you please store the last used path in the .prefs file please?
So that we don't need to navigate to the history.db folder each time we start the tool

Here, however, I haven't yet decided on the order of opening priorities.
For the moment, it's as follows:
1) Open the default file
2) If unsuccessful, ask the user for a new location and store the folder in the prefs file.

My concern is that if I try to open the last file used in a previous session and it's not available (path not found or file deleted), what do I do next?

I think I'll do it this way:
1) First try to open the default file
2) If unsuccessful, if a last used file has been saved and is available, try to open it.
3) If unsuccessful or no last file, don't open any file and the user will choose from the combo list if there are any, or add folders via the preferences window.

What do you think about this?

(for a tiny tool that intended to be as small and simple as possible, it start to be more complex . )

[boddhi]

PS : I now realize that I may have made life a little more complicated by adding and managing a preferences window.
In French, we say "Le mieux est l'ennemi du bien". "The best is the enemy of the good" exists in English?

[highend]

What do you think about this?

Sounds good for me

(for a tiny tool that intended to be as small and simple as possible, it start to be more complex . )

It's still simple, at least for the user side (and a lot more convenient than before)