The Database Update - Oops

The library used for database access had to be replaced. The good news is that the new library is several times faster. The bad news is that testing will have to be repeated and the beta period will be extended.

Thanks for all the help. The feedback has been great.

The Database Update - Finale

The bulk of the work is done for the current Beta or ArsClip. The remaining work left to be done is just polishing and testing.

Notification has been improved. A small tooltip will appear at the top/left of the current program to show information about events. For example, when a Per-Program option is used to override default settings, a visual cue is shown. The cues are designed to let a user know why ArsClip isn't behaving like normal.

If everything is a clip, a single window is used for managing clip history and permanent clips makes the most sense. This removes a lot of clutter and makes things a bit more intuitive. It's now trivial to copy a clip from history and create a permanent clip with it.

The conversion to a real database ultimately serves one purposes: sharing the data. This allows ArsClip to share a clipboard and to be compatible with running ArsClip from a synced or shared location. A future goal is to share data with the Android version of ArsClip.

The Database Update - Part 6

Though it was dreaded, the Permanent Clips/Macros and Edit History windows no longer makes sense as separate windows. The two have been combined into a single "Edit Clips" window.

This change means a few things. It's a good time to fix the issues with these old windows. Copying clips from another instance will be more intuitive. And, it's also going to delay the next Beta.

The Database Update - Part 5

Automation

ArsClip has a few well known execution methods. The most popular, by far, is running from the local hard drive. All other methods of execution serve one purpose: to copy the program anywhere and it will just work.

Windows has plenty of options to ensure data integrity when multiple programs or users all want to use the same shared file. There's nothing useful for programs that are disconnected. It's the same problem that existed when Palm Pilots were popular. Two disconnected programs that try to share data once connected can overwrite each others changes. This is effectively the same issue with cloud syncing.

To have ArsClip work as expected and run from "anywhere", some automation is needed. First, ArsClip will detect when it is run from a USB drive. In this mode, ArsClip will use a single database to for clips. Second, ArsClip will detect when it is run from a remote folder (UNC or mapped drive). Lastly, it will run in compatible mode for a normal local install that may be cloud synced.

The effect is as follows: USB users will see the same data no mater what computer they use. Remote users (cloud/shared folder) will always see device dependent data. ArsClip will use the name of the current computer to individualize clips. Local drive users follows the same rules as the remote users, but effectively will only see the same data. The name of the computer is used to individualize databases.

There is still work to be done to cover the cases when a local install is moved to a USB or when a local install is moved to another computer. For the latter, some user interaction may be required.

The Database Update - Part 4

"Never" was the answer for when I would add an option to share a clipboard. Technically, this answer is the same today. ArsClip does not send clips to other instances over the Internet. ArsClip will be cloud compatible, but it won't directly use the cloud nor will it require and Internet connection.

The new test version does allow for a Global Clipboard via a configuration option, but you have to provide the mechanism for connections. To do this, all instances run from the same folder use a single location to save information about the instance and the changes to the local clipboard. This means that all you need to do is provide a way for other computers to access the ArsClip folder. A network share, VPN, mirroring utility, or cloud folder sync program can perform this task. The ultimate end is to also allow ArsClip Mini to do the same thing, but Android will need to use a cloud App service exclusively as the mechanism for connection.

The Database Update - Part 3

First, a big thank you to to all the beta testers. There are so many cases to test that I miss on my own. For example, I forgot about the date routines on non-US English systems. I also forgot to test running the program on a clean install.

The current test versions do just enough get the existing code to work with the database. Many of the previous design choices made aren't needed and are inefficient. The next changes will be to improve the code to make better use of database.

EDIT: The Plans and Ideas section for ArsClip has been updated.

The Database Update - Part 2

Code that has not been touched in years was reworked/replaced to support database storage. It was a lot of work, but the code is now cleaner and more reliable.

Permanent Clips are now imported in the database. The "everything is a clip" design works well. There are no more special cases to handle. Removed Clips can be deleted without having to erase the entire cache.

There's still more work to be done. For example, the program still relies on Permanent Clips/Macros having a folder, even though the program reads and writes to the database.

Lots of bug, including many old bugs, have been fixed in the latest update. For example, the Removed Clips list in Edit History didn't show new clips as they were added when the form was open.

The Database Update

The current Public Beta test of ArsClip imports all data into a single database file on the first run. After the import, all reads and writes are perform on the database. On most systems, the import is so quick that it won't be noticed.

The Removed Clips tab in Edit History is much faster. Instead of hundreds of reads on small files, one read is performed on an optimized file format. Removed Clips can now easily handle thousands of clips. Also, it will be possible to delete clips from the Removed Clips in a future test version.

Popup Clips still work the same as before. They are stored in memory for speed. In the background, the list is periodically stored to disk. These clips are marked with the name of the machine that ArsClip is running. Each machine has its own list.

This database change is also for cloud compatibility. When the ArsClip folder is synced with a cloud utility, there won't be any conflicts with multiple instances overwriting data. The down-side is that then entire database file must be uploaded, instead of just the new/changed files.

The database used is SQLite3. It is a popular cross-platform specialized format for running on a single machine. It's what Android uses, so it's perfect for later integration. This also means that advanced users can use one of the many open source GUIs to view and edit the database.


The current TODO list for upcoming test versions:
- change Edit History to show Popup Clips from other machines
- change Edit history to allow deletes of Removed Clips
- implement a "shared clipboard" option
- fix bugs

The current IDEAS list:
- investigate if having an option for "on disk" popup clips, instead of in-memory, is a good idea