Quote from: mouser on February 14, 2020, 03:43 AM

I'd be curious if folks would prefer to have image data stored in the normal clip database as well?

For me, keeping the database robust trumps duplication.

• I've migrated the core clipboard capturing and pasting functions from using a single format (plaintext or image), to using a multi-format "blob" data structure.
• So when capturing it captures all formats in the clipboard and saves the collection (blob) of formats in the database.
• It has some basic options for what formats you want it to ignore, and tries to identify redundant formats that can be ignored, for example unicode/oemtext/dib bitmaps that are equivalent to other stored formats.
• It also handles plaintext and images specially; while preserving their order in the blob collection (if multiple formats found), it pulls out images to external png files with comments, and pulls out plaintext to sit in the database as a separate searchable field.  In this way, I'm hoping to get the best of both worlds (multi-format support but more convenient access to plaintext and images and minimizing database size).
• Order of the multiple formats in a blob is preserved even in the case of images and plaintext, which may occasionally be important to some scenarios.
• A single checkbox in the option will toggle the program from capturing multiple formats vs the old pure-plaintext behavior of CHS, so if you don't want the new formats and prefer a leaner pure plaintext database you can still use CHS that way.
• Duplicate checking should be somewhat improved, and work for multiple-format blobs and images.

• Lots more testing -- I'm hoping to get some help with that from the forum.
• There are a bunch of ancillary things regarding copying+pasting that I might not have fully implemented in the new code (flashing clipboard icon on capture, dealing with stubborn situations where the clipboard is being used by another app, updating clip modification dates on pasting, etc.).
• There are a few functions that are specifically plaintext related, like when performing format presets, and pasting text using sendkeys, that I have not fully moved over, or that use some old code.  I still have to go through and update all of those functions.  They will will only work with plaintext, but I think the existence of multi-format blob data may confuse some of these functions.
• Similar behavior might be expected after manually editing a clip -- you will have changed the PLAINTEXT content of the clip, but not the unicode/richtext version, So I think what has to happen in such cases is a clearing of the unicode/richtext data in such cases.
• I want to add more features to help you see how much space is being used by the multi-format data, and to do some maintenance operations on it to keep your database lean (like functions for removing multi-format data from old clips, etc.).
• I would like to add more flexible rules for deciding which formats you want saved.. For example being able to specify a custom list of formats to keep or ignore, and maybe setting arbitrary limits on size, or based on the application running.  I'm not sure the best way to do this that would satisfy experts and novices alike..
• Verify that the new image capture/pasting DIB format works in all cases.

Quote from: djMot on February 18, 2020, 02:21 PM

I'm still not seeing images in a the HTML Preview tab. 

Try re-downloading to get the latest version and then enable this option:
[attach=1,msg436221]

Is there a database schema somewhere so we can understand what's available to construct a WHERE clause from?

it's very nice that the url is saved when copying text from a webpage

The vector clips from Freehand shown here are identical:

The vector clips from Freehand shown here are identical:

• 1. Live with it and don't worry about having duplicate clips in such a case since it won't happen too often.
• 2. Wait for rules that would let you ignore blob items irrelevant to the content, which could solve your problem if the timestamp (or whatever) is not the main vector content.
• 3. I may add display of hash values for the individual format chunks in a blob so you could ID which one is changing..

Ok, so what you are saying is you copied something multiple times, and CHS is not figuring out that the clips are identical and should be regarded as duplicates?
I noticed this happening in firefox too, but as you point out, the hashes were different, so I'm guessing that their is something in the blob data that is NOT identical, like perhaps a timestamp.

The solution to this is:

    1. Live with it and don't worry about having duplicate clips in such a case since it won't happen too often.
    2. Wait for rules that would let you ignore blob items irrelevant to the content, which could solve your problem if the timestamp (or whatever) is not the main vector content.
    3. I may add display of hash values for the individual format chunks in a blob so you could ID which one is changing..