chrome.webview.hostObjects.foo_uie_webview.execute(filePath, parameters, directoryPath, operation, showMode);

        chrome.webview.hostObjects.sync.foo_uie_webview.execute(filePath, parameters, directoryPath, operation, showMode);

const handleList = MetaDBHandleList(...);
handleList.release();
handleList.count;  // 50 but it's not true xd It should either throw or report 0

    this.release = function () // Using any method or getter will return safe values and do nothing
    {
        const n = this.count;
        for (let i = 0; i < n; ++i) {delete this[i];}
        this.count = 0; // Choosing this instead of void to not invalidate the iterator
        this.release = () => void(0);
        WebView.releaseMetaDBHandleList(this.Source);
        this.Source = void(0);
    };

    this.release = function () // Using anything will either throw or return undefined
    {
        WebView.releaseMetaDBHandleList(this.Source);
        Object.keys(this).forEach((key) => delete this.key);
    };

    /**
        Gets the path.
        @type {string}
    **/
    this.path; // It doesn't mind whether it's set as undefined or just accessed.
    Object.defineProperty(this, 'path',
    {
        get() { return WebView.getMetaDBHandlePath(this.Source); }
    });

const WebView = chrome.webview.hostObjects.sync.foo_uie_webview;

foo_uie_webview v0.3.0.0-alpha1

    * execute(filePath, arguments, directoryPath, operation, showMode): Execites a shell operation on a file.

About the wrapper:

- Line 36:

Code: [Select]

        chrome.webview.hostObjects.foo_uie_webview.execute(filePath, parameters, directoryPath, operation, showMode);

Should be (missing .sync.):

Code: [Select]

        chrome.webview.hostObjects.sync.foo_uie_webview.execute(filePath, parameters, directoryPath, operation, showMode);

- Same error at line 74 and 84

- Class MediaLibrary, I would say this method should be getter (unless I misunderstood something, it returns directly a property and is not a method: isEnabled

- Class Foobar2000, should be getters: canReadFiles, canReadDirectories, canExecuteShellOperations

- As commented by PM, the MetaDBHandleList constructor may need additional things if you plan to add methods to remove/add handles to it. In any case, the count could be internally cached. Since it's fixed at creation and only changes whenever you add/remove items (which can only happen under user request by specific code).

- MetaDBHandleList: I think at release method you should also delete the actual pointers in the object, otherwise the object itself will be pointing to another undefined object. As result doing things like:

Code: [Select]

const handleList = MetaDBHandleList(...);
handleList.release();
handleList.count;  // 50 but it's not true xd It should either throw or report 0

Will probably either crash your component unless you check all the inputs to be valid (not sure if you are already doing that), crash the JS logic or simply behave wrong. After .release(), this.Source points to a non existent entity, with no indexes. All the properties of the parent should be deleted or set to safe values.

Code: [Select]

    this.release = function () // Using any method or getter will return safe values and do nothing
    {
        const n = this.count;
        for (let i = 0; i < n; ++i) {delete this[i];}
        this.count = 0; // Choosing this instead of void to not invalidate the iterator
        this.release = () => void(0);
        WebView.releaseMetaDBHandleList(this.Source);
        this.Source = void(0);
    };

or just

Code: [Select]

    this.release = function () // Using anything will either throw or return undefined
    {
        WebView.releaseMetaDBHandleList(this.Source);
        Object.keys(this).forEach((key) => delete this.key);
    };

Quote from: pqyt on 2024-12-27 21:14:59

foo_uie_webview v0.3.0.0-alpha1

Also, I noticed that onPlaylistItemsReordered returns just a list of numbers for the items parameter (one number for each item in the playlist) and that they are always just numbers in order: [0, 1, ..., n-1, n]. Ignoring the fact that a list of numbers isn't all that helpful, I'm guessing the plan will be things like this return a list of handles?

Quote from: pqyt on 2024-12-27 21:14:59

foo_uie_webview v0.3.0.0-alpha1

Noticed that if user has not enabled reading directories, but script still attempts to we get a "Class not registered" error. Is there a more descriptive error that can be returned here?

All WebView2 host object methods can be either synchronous or asynchronous by adding or omitting ".sync.".

chrome.webview.hostObjects.foo_uie_webview

chrome.webview.hostObjects.sync.foo_uie_webview

At this point I don't see a scenario *yet* in which JavaScript 'creates' a MetaDBHandleList. It is a wrapper around an unmanaged resource. The lifespan is currently determined by the component.

That will not work: the handles in the handle list are owned by fb2k. Releasing the list destroys all its items. You're not supposed to be release the 'item' handles yourself.

I haven't really looked into the whole error reporting business. What's the most suitable/used pattern used in JavaScript knowing I can't raise JS exceptions from the C++ code?

Quote

All WebView2 host object methods can be either synchronous or asynchronous by adding or omitting ".sync.".

I see, thought it was an error. That kind of nesting makes things a bit more difficult, since there are 2 webView namespaces.

Code: [Select]

chrome.webview.hostObjects.foo_uie_webview

Code: [Select]

chrome.webview.hostObjects.sync.foo_uie_webview

No idea how are you doing it, but obviously it would be much more simple if sync/async methods are just called using flags or different names within the same namespace.

Quote

At this point I don't see a scenario *yet* in which JavaScript 'creates' a MetaDBHandleList. It is a wrapper around an unmanaged resource. The lifespan is currently determined by the component.

For ex. at some point you may want to merge 2 handle lists or add tracks by some queries to a handle list and then send it to a playlist (instead of sending every track to a playlist which would be much slower).

Release method takes care of the actual handles, but if you are wrapping it, you also have to clean the wrapper and make sure its methods don't work anymore, throw or output safe values.

Quote

I haven't really looked into the whole error reporting business. What's the most suitable/used pattern used in JavaScript knowing I can't raise JS exceptions from the C++ code?

In SMP the error throws a message, the line of code and callstack that lead to that line of code. Except for really complex code, it usually gives you pretty clear clues about what's going wrong.

Quote from: MordredKLB on 2024-12-29 05:59:44

Also, I noticed that onPlaylistItemsReordered returns just a list of numbers for the items parameter (one number for each item in the playlist) and that they are always just numbers in order: [0, 1, ..., n-1, n]. Ignoring the fact that a list of numbers isn't all that helpful, I'm guessing the plan will be things like this return a list of handles?

I currently expose the fb2k API as 'raw' as it gets. This is what API gives me. I can sugarcoat this in C++ but then every developer gets the extra added weight. Don't you think it's better to add the sugarcoating in the new 'foobar2000.js'?

Quote from: pqyt on 2024-12-29 09:07:37

Quote from: MordredKLB on 2024-12-29 05:59:44

Also, I noticed that onPlaylistItemsReordered returns just a list of numbers for the items parameter (one number for each item in the playlist) and that they are always just numbers in order: [0, 1, ..., n-1, n]. Ignoring the fact that a list of numbers isn't all that helpful, I'm guessing the plan will be things like this return a list of handles?

I currently expose the fb2k API as 'raw' as it gets. This is what API gives me. I can sugarcoat this in C++ but then every developer gets the extra added weight. Don't you think it's better to add the sugarcoating in the new 'foobar2000.js'?

I do think for some things (possibly the Error responses?) foobar2000.js is the way to go.

This one is weird, because it's always just numbers in order, one for each item in the playlist. The order of the numbers never changes even when you reorder songs.... it just is always the same 0 to N. If there's no plan to ever have it return handles, then it probably shouldn't return anything because the numbers don't actually mean anything.

The numbers do mean something: they are the indexes in the original playlist but in a new sequence. The callback is actually a misnomer: your code gets called 'after' the reordering has happened but 'before' the playlist has been updated on the screen. onPlaylistReordering() would be better.

WebView 0.2.1.0 not working (empty field). Foobar2000 1.6.18.

Requirements
> foobar2000 v2.0 or later (32 or 64-bit)

Oh, when did that happen?
Isn't it from v0.3.0.0-alpha?