Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Spider Monkey Panel (foo_spider_monkey_panel) (Read 349834 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #675 –
Quote from: TheQwertiest on
Should be fixed in the latest nightly.
Verified. Wasn't a big deal for me since I was always using a IsFolder() helper method so it was a one line fix, but this is still simpler.

Quote
I've added `iterator` support to iterable ActiveXObjects. Now you can write it like this:
Code: [Select]
for (let f of p.SubFolders) {
  DoSmth(f);
}
Much cleaner. Thanks so much!

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #676 –
I'm experimenting with getters and setters in classes. The following code crashes foobar (crash reports submitted). What am I doing wrong?
class _procNewFiles{
    constructor() {
        this.state = -1;
        this.myHandles;
        this.folders = [];
    }
    get state() {
        return this.state;
    }
    set state(v) {
        this.state = v;
    }
}

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #677 –
Quote from: Black_Over_Bills_Mothers on
I'm experimenting with getters and setters in classes. The following code crashes foobar (crash reports submitted). What am I doing wrong?
What version of SMP are you using?

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #678 –
Spider Monkey Panel v1.3.2-beta+718c0702 by TheQwertiest
Based on JScript Panel by marc2003
Based on WSH Panel Mod by T.P. Wang

Build: 15:12:55, Feb  7 2021
Columns UI SDK Version: 6.5

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #679 –
Quote from: Black_Over_Bills_Mothers on
Spider Monkey Panel v1.3.2-beta+718c0702 by TheQwertiest
Based on JScript Panel by marc2003
Based on WSH Panel Mod by T.P. Wang

Build: 15:12:55, Feb  7 2021
Columns UI SDK Version: 6.5
Can you pm me a crash dump? (latest .dmp file from `foobar2000/crash reports`)

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #680 –
Quote from: Black_Over_Bills_Mothers on
I'm experimenting with getters and setters in classes. The following code crashes foobar (crash reports submitted). What am I doing wrong?
class _procNewFiles{
    constructor() {
        this.state = -1;
        this.myHandles;
        this.folders = [];
    }
    get state() {
        return this.state;
    }
    set state(v) {
        this.state = v;
    }
}
Also, are you sure that this is the whole script that you are executing? And not just a part of it?
I need the full script if I want to repro the crash.

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #682 –
Quote from: Black_Over_Bills_Mothers on
I'm experimenting with getters and setters in classes. The following code crashes foobar (crash reports submitted). What am I doing wrong?
class _procNewFiles{
    constructor() {
        this.state = -1;
        this.myHandles;
        this.folders = [];
    }
    get state() {
        return this.state;
    }
    set state(v) {
        this.state = v;
    }
}

Not an expert here, but I think the problem is that the getter and setter can not have the same name as the property they read and write.
I'm late

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #683 –
Quote from: davideleo on
Quote from: Black_Over_Bills_Mothers on
I'm experimenting with getters and setters in classes. The following code crashes foobar (crash reports submitted). What am I doing wrong?
class _procNewFiles{
    constructor() {
        this.state = -1;
        this.myHandles;
        this.folders = [];
    }
    get state() {
        return this.state;
    }
    set state(v) {
        this.state = v;
    }
}

Not an expert here, but I think the problem is that the getter and setter can not have the same name as the property they read and write.

Hey. That fixed it. Many thanks. I'm sure TheQwertiest will fix the crash though. I would have thought MS Code would flag it as an error but it didn't.

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #684 –
Quote from: davideleo on
Quote from: Black_Over_Bills_Mothers on
I'm experimenting with getters and setters in classes. The following code crashes foobar (crash reports submitted). What am I doing wrong?
class _procNewFiles{
    constructor() {
        this.state = -1;
        this.myHandles;
        this.folders = [];
    }
    get state() {
        return this.state;
    }
    set state(v) {
        this.state = v;
    }
}

Not an expert here, but I think the problem is that the getter and setter can not have the same name as the property they read and write.
There's nothing illegal about having the getter/setter return the same property... it's just almost always not what you intend to do unless you're doing something fancy and intentional like lazy getters, etc.

As written, his getter would return the function (or possibly the constructor has overwritten the getter? I probably should know this), and his setter would overwrite the getter if it still exists.
 

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #685 –
Just a question, I have not checked your latest changes on the properties panel so I don't know if it's relevant.

Quote
-Properties descriptions change according to things set on the panel, not just the values. i.e. if you change the sort method using the contextual menu, then the description on the panel reflects the associated states dynamically.
[attach type=image]18981[/attach] IMAGE HERE -> https://hydrogenaud.io/index.php?topic=120394.msg993688#msg993688
What about an on_properties_panel_change(name) callback? That way we could recreate the descriptions (and add allowed values) on the fly.

Right now I have managed 2 use-cases:
-User sets property A using contextual menu. -> old Property B gets removed. -> Property B gets rewritten and set according to A. Example:
A: Sorting method: by Size -> B: Asc or Desc: Asc
=> A: Sorting method: by Name -> B: Az or Za: Az

-Main script has property A with empty value -> On init, checks if A is empty. -> old Property A gets removed.  -> A secondary file loads a list of values and sets the default one to property A. Description changed accordingly too. - > Property B set according to A, ...
Example:
A: Sorting method. (Allowed by): ''  -> A: Sorting method. (Allowed by Name, by Size): size  ->  B: Asc or Desc


Both require removing old properties and setting new ones. But that only works because I previously know all values.

If the user edits the properties panel directly, on first use case this is what happens:
-User sets property A using contextual menu. -> Nothing is removed because it was not empty -> Property B gets automatically rewritten according to A and set.

So I get 2 times the "same" property B but with different descriptions.
X

Since I don't know the description of the old property B because A has already changed, I can not do anything about it. A callback with the description of the property changed would solve that. I would get A description and then get the associated B description and remove it. And I'm sure the callback would be useful for other uses.

Another possibilities/solutions would be:
- Function to clear all properties. That way, if the panel changes, I can simply recreate all new properties at once (not having to care about what's old and what's new.
-Being able to iterate all properties of a window.

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #686 –
Quote from: MordredKLB on
There's nothing illegal about having the getter/setter return the same property...

That's not what I wrote, though. The getter and the setter can return the same property, of course, but they cannot return themselves.


EDIT: I just googled "lazy getters", didn't know about this pattern.  I see what you mean now.
I'm late

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #687 –
Quote from: Black_Over_Bills_Mothers on
I'm experimenting with getters and setters in classes. The following code crashes foobar (crash reports submitted). What am I doing wrong?
Fixed component crash in the nightly (once it's built), now it will crash JS instead =)

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #688 –
Quote from: regor on
What about an on_properties_panel_change(name) callback?
This one won't be implemented: panel properties can only be changed by the SMP user and can't be changed by the SMP itself, so it makes no sense to make such callback.

Quote from: regor on
- Function to clear all properties. That way, if the panel changes, I can simply recreate all new properties at once (not having to care about what's old and what's new.
-Being able to iterate all properties of a window.
These could be implemented via properties_v2 that I've mention before (when it's done).

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #689 –
Version: 1.4.0
Link: https://github.com/TheQwertiest/foo_spider_monkey_panel/releases/tag/v1.4.0
Changelog:
Spoiler (click to show/hide)
Detailed description of API changes: https://theqwertiest.github.io/foo_spider_monkey_panel/docs/script_documentation/api_changes/#v140

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #690 –
Been playing around with 1.4 and it seems pretty solid. No issues on my end. Great work!

In looking at the new packages feature, and it's very interesting, but I'm wondering whether it's worth it to switch over to this distribution method. Right now users of my theme just download my repo and extract it to a specific folder (which occasionally causes issues because people can't find the profile folder). When they want to upgrade they just do the same thing and overwrite the existing files which seems to be working pretty well. At initial install they have to copy a 1-liner include command which includes a loader.js file which then does all the including of all the other .js files, etc., but then they never have to touch the config screen again.

Presumably creating a package will essentially just perform the same function? It would just change where the files would need to be extracted, right? My only external assets that aren't created by the theme itself are in an /images folder so they're already segregated from the rest of the code.

Are there other benefits that I'm missing?

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #691 –
First "bug": Properties tab, clicking clear and then apply does not refresh the list as it always did. The same for deleting.

Also, changing the panel name when already using DefinePanel() inside the script does nothing.  DefinePanel() takes priority and change gets reverted.
But using DefineScript() at the same place, the panel name set at configure takes priority. Is that intended?

Looks good so far! Thanks! Specially love the in memory/ from file setting. I was so tired of having to re-import the main script to load the last changes if they were on the main file.

Quote
Are there other benefits that I'm missing?
As far as I have seen, the paths are relative. So you can include tons of files without overwriting others. Your theme for example is a single modification intended to be use standalone, but if you use different scripts it's easy to see file conflicts.

For ex. when I release the graph scripts, buttons framework and the playlist manager, all of them use the same helpers. Whenever I update one of them I will have to update the entire list of files for every other release, otherwise I will have "graph scripts" expecting a version of X helper different to "playlist manager scripts". Note your users just have scrip Theme v x or Theme v Y, so upgrading means replacing X with Y and done. Other use cases involve people having script A vx and Script B vy.... and upgrading Script B should not mean replacing files from A too. But that happens right now if you use the same filenames in both releases.

In a package, I would simply put my new changes in the new package and other packages would work with its own version of the 'same' files. It can be done changing manually names on include() but this greatly speeds up  the thing. Most game mods work similar, they are added using relative files path.

It seems that in the same spirit than "mods", the package has a description, etc. So you can explain a bit what the thing does without expecting the user will read a comment in the js file or a readme.txt.

X

Have no idea if there are more benefits.

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #692 –
If the "foo_wave_seekbar" component is installed, then when editing scripts directly in the panels themselves, the player crashes. This has been the case in recent JS releases

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #693 –
Assuming it's the same bug as I had, ListBoxX_ClassName needs updating to something unique.

https://github.com/TheQwertiest/scintilla/blob/f8817063200055b8b9f7b9a7a83c30100f64c903/win32/PlatWin.cxx#L2533

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #694 –
Quote from: MordredKLB on
Are there other benefits that I'm missing?
Well, off the top of my head:
- Package is installed and unpacked automatically either via `Import` button or just by drug-n-dropping. So users don't need to know the "correct" location (or the correct folder structure).
- Packages has persistent id, meaning that the path to package content is always persistent and can be relied upon (e.g. by other packages).
- User can easily switch between packages in a single panel without needing to copy-paste script content anywhere.
- Same package can be reused in multiple panels (again, without needing to copy-paste script content).

Quote from: regor on
First "bug": Properties tab, clicking clear and then apply does not refresh the list as it always did. The same for deleting.
I'll look into it, thanks.

Quote from: regor on
Also, changing the panel name when already using DefinePanel() inside the script does nothing.  DefinePanel() takes priority and change gets reverted.
But using DefineScript() at the same place, the panel name set at configure takes priority. Is that intended?
Yes, that is intended.
As per docs (https://theqwertiest.github.io/foo_spider_monkey_panel/assets/generated_files/docs/html/window.html#.DefinePanel and https://theqwertiest.github.io/foo_spider_monkey_panel/docs/script_documentation/api_changes/#v140): "Note: to retain backward compatibility this method sets both script name and panel name."
That's why it was marked as deprecated =)

Quote from: regor on
Looks good so far! Thanks! Specially love the in memory/ from file setting. I was so tired of having to re-import the main script to load the last changes if they were on the main file.
Glad that you liked it :)

Quote from: regor on
As far as I have seen, the paths are relative.
Relative path support was there even in the previous SMP versions =)
The only difference is that package scripts dir is included in the search path now.

Quote from: snotlicker on
Assuming it's the same bug as I had, ListBoxX_ClassName needs updating to something unique.

https://github.com/TheQwertiest/scintilla/blob/f8817063200055b8b9f7b9a7a83c30100f64c903/win32/PlatWin.cxx#L2533
Thanks for the tip!

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #695 –
Quote
Relative path support was there even in the previous SMP versions =)
The only difference is that package scripts dir is included in the search path now.
I meant relative to the package yep. That changes many things.

Quote
Yes, that is intended.
As per docs (https://theqwertiest.github.io/foo_spider_monkey_panel/assets/generated_files/docs/html/window.html#.DefinePanel and https://theqwertiest.github.io/foo_spider_monkey_panel/docs/script_documentation/api_changes/#v140): "Note: to retain backward compatibility this method sets both script name and panel name."
That's why it was marked as deprecated =)
I was not talking about the funcs, but the UI behavior. The option should be greyed out if the script contains a call to DefinePanel(), or some UI warning in the panel: NAME + (non configurable: set by script). It's counterintuitive for users to change something and be reverted without notice, since your main aim was to ease things for final users.

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #696 –
Hi everyone,

I have a small problem using XMLHTTP object. It generates the following error:
ActiveXObject:
source: msxml3.dll
description: Error not specified

This is an extract of the code I use to get this error (I'm using Typescript)

let xhttp = new ActiveXObject("Microsoft.XMLHTTP");
return new Promise((resolve, reject) => {
   xhttp.onreadystatechange = function () {
      if (xhttp.status === 200) {
         if (xhttp.readyState === 4) {
            resolve(xhttp.responseText);
         } else {
            reject("Error");
         }
      } else {
         reject("Error");
      }
   };

   const album_url = `http://localhost/api/v1/album/get?album_id=${album_id}`;
   xhttp.open("GET", album_url, true);
   xhttp.send();
}
I use foo_spider_monkey_panel 1.4.0
Any idea where this error could come from ?
Thx for your support.

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #697 –
Quote from: cerbaire on
Any idea where this error could come from ?
Thx for your support.
It seems that it's not allowed to access `status` before `readyState` is 'Done' (i.e. equal to 4). And yes, MS should've done a much better job with the error message in such case :D

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #698 –
@regor , @kutuzof , all reported issues should be fixed in the dev build.

Re: Spider Monkey Panel (foo_spider_monkey_panel)

Reply #699 –
Quote from: TheQwertiest on
Quote from: cerbaire on
Any idea where this error could come from ?
Thx for your support.
It seems that it's not allowed to access `status` before `readyState` is 'Done' (i.e. equal to 4). And yes, MS should've done a much better job with the error message in such case :D
Thanks @TheQwertiest, it works great now.
One question: I wonder if it is possible to package a multiple panel theme with the last release of your plug-in. It seems we can easily package a single panel theme. What if I have 5 panels ?
Many thanks for all the job you've done.