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: WSH Panel Mod (Read 813786 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

WSH Panel Mod

Reply #1650 –
although some of my previous changes have forced some scripts to be updated, those very same scripts should still work with the official component v1.5.0 and onwards. if i were to make the changes you suggest, then it would break compatibility completely and any script would only work with the very latest component. i'm reluctant to make a change like that.

WSH Panel Mod

Reply #1651 –
so maybe replace the term "migrate" term by "duplicate" in my previous post, so it won't break any compatibility with 1.5.x versions, but in 5 years, it will be the time to remove the old fb playlist methods as they have been marked "do not use but prefer plman ones for new scripts" in v1.6.x version...

btw, just a suggestion because having fb.CreateAutoplaylist and no more fb.CreatePlaylist it's confusing too (especially for new users).

WSH Panel Mod

Reply #1652 –
i suppose it would be better for consistency to have plman methods for all playlist operations so i'll add them.

WSH Panel Mod

Reply #1653 –
You could implement a compatibility shim as a script. The shim would provide the functions you moved or deleted. The decision whether to load the shim would be based on a version tag in the script header. The version tag would declare for which version of the component the script was written. The preprocessor would check this tag. If the declared version requires the shim the preprocessor loads the shim before the actual code. The declared version should be passed to the shim so it can decide which functions it needs to provide. That way you need less version checking logic on the C++ side. The shim would be loaded from a DLL resource just like the default script.

Pros:
- You can get rid of obsolete code on the C++ side as long as you can implement the removed logic in the shim on top of the remaining API.

Cons:
- You need one shim per script language/engine. Of course, you could restrict the component to support only one script engine.
- Script objects based on IDispatch do not support monkey patching, for example to extend an object implement in C++ with a method written in JScript. This would require support for IDispatchEx. I've done a bit of research and it looks like a pain to implement.

WSH Panel Mod

Reply #1655 –
I have just one request..
Can you make properties window resizable, that properties remember it's size.

WSH Panel Mod

Reply #1660 –
i've decided to get rid of "safe mode" completely. now anyone following instructions to disable it won't be able to find it. 

Code: [Select]
v1.6.1 Beta2
- ADD: plman.CreateAutoplaylist, plman.IsAutoPlaylist, plman.ClearPlaylist
       These are in addition to the "fb" methods which already exist.
- CHG: "Safe mode" is no longer an option.
- CHG: Tidy up samples.


https://github.com/19379/foo_uie_wsh_panel_mod/releases

WSH Panel Mod

Reply #1661 –
I have a  problem with this change made a few releases ago, and I only just realised it  affected me.

CHG: Remove on_tooltip_custom_paint() callback.

This is not my script, and the person who wrote it is  unlikely to update it.

The problems are:

1.    Tooltips no longer work in the script.

2.    The script uses on_tooltip_custom_paint(gr).  This enables the tooltips to have a custom font & font size. It's unclear to me  how to use custom tooltip font & font sizes with the tooltip functionality  that remains. I want to use a tooltip font & font size that matches the  displayed text. The remaining tooltip methods seem to use the windows default  tooltip size that I don't want to change for other reasons.

3.    A  consequence presumably of the missing callback is that the script crashes as  soon as it goes over text that requires a tooltip to be drawn. 1.5.12 works  correctly.

Seeing as  this callback seems to provide functionality not provided by another mechanism,  I think it should remain. Else please give some hints as to the how tooltips  can be used with custom fonts and font sizes.   

One other  thing that I think would be useful if within your capabilities is:

fb.GetQueryItems(query,  sort = "") returns a handle list for the query, ideally sorted

i.e.  something like a silent version of CreateAutoPlaylist with the same query and  sort syntax

fb.CreateAutoPlaylist(idx,  name, query, sort = "", flags = 0)   

fb.GetQueryItems()  is likely to be much faster and easier than analysing the whole library items  with EvalWithMetadb(IFbMetadbHandle) which is relatively slow (~200 msec for  25K library). If fb.GetQueryItems() is used, the EvalWithMetadb(IFbMetadbHandle)  would then only have to be done on the much smaller list returned by  fb.GetQueryItems(). It currently can be done by transiently generating  autoplaylists. In my tests this typically takes 25 msec on 25K library vs the  200 msec the other way. This difference becomes even more significant if  multiple library checks are done one after another.

WSH Panel Mod

Reply #1662 –
the reason i removed it is because i've never seen a working example. i even asked T.P Wang how to use it many moons ago but he misinterpreted my question and never answered. all i could find on google was this but i can't see anything happening with v1.5.6 or v1.5.12.

http://pastebin.com/7pnQYm8E

i'll look into your second request but it will probably be beyond me. 

WSH Panel Mod

Reply #1663 –
Well yes that's the one I mean that uses on_tooltip_custom_paint() callback - original is here (last update 17 May 2015 for 1.5.6+):

http://thanhdat1710.deviantart.com/art/WSH...-V1-0-376360761

Why can't the callback be retained, as it seems to offer something that can't be done by other means, i.e. custom tooltip fonts and font sizes? The script referenced has had 759 downloads so its not exactly unpopular.


 

WSH Panel Mod

Reply #1664 –
you can call me all the names under the sun but i've decided i'm not going to restore that functionality.

reasons:
-i've never seen any other program/component/panel with the functionality
-i've never seen anyone complain that standard tooltips weren't adequate - obviously they still work in the latest components when implemented properly
-people with a genuine need for larger fonts are going to be changing their screen resolution/DPI settings and not relying on one WSH panel mod script.
-you can use foo_uie_wsh_panel_mod_plus to run that script. it's based on v1.5.6 but because its internal name is different, it can run side by side with any version of WSH panel mod.
-if you don't want to use that alternative component, i know you have the skills to fix that script so it doesn't crash. having checked, it crashes when trying to set tooltip width/height properties that no longer exist.

incidentally, looking at the source code for that plus component, it has a query function which does exactly what you asked for so i can copy it.

WSH Panel Mod

Reply #1665 –
Quote from: marc2003 on
i've never seen any other program/component/panel with the functionality


Well for example both the default DUI albumlist browser and es_playlist automatically use tooltips that match the font and font size of the list. It looks rather odd in a playlist or browser having tooltips with non-matching fonts/sizes (e.g. too small). So if a larger font is set in DUI colours & fonts these components use that for the tooltip. The script in question is a browser.

WSH Panel Mod

Reply #1666 –
i have messed around with larger fonts before but i guess the reason i didn't notice the tooltips before is because my panels are still large enough so things don't get truncated.

WSH Panel Mod

Reply #1667 –
i've added a different way to set a custom tooltip font/size. i didn't want to restore the previous method because it was loads of code compared to this which is only a handful of lines.

Code: [Select]
v1.6.1 Beta 3
- ADD: window.CreateToolTip now takes optional font name and font size (px)
       arguments. eg window.CreateToolTip("Segoe UI", 32);
       Defaults of "Segoe UI" and 16 are used if omitted.
- ADD: plman.GetQueryItems(source_handlelist, query) returns an unsorted
       handle list. Consider using OrderByFormat, etc on the result
- ADD: plman.CreateAutoplaylist, plman.IsAutoPlaylist, plman.ClearPlaylist
       These are in addition to the "fb" methods which already exist.
- CHG: "Safe mode" is no longer an option.
- CHG: Tidy up samples.


https://github.com/19379/foo_uie_wsh_panel_mod/releases

an example:

WSH Panel Mod

Reply #1668 –
thank you, plman.GetQueryItems will be very usefull for search or filters

as you are in plman, one request: ClearPlaylist only work on the active playlist, it doesn't take any playlist idx in argument and that's a shame in some uses... could you see if it's would be possible to add the playlist_idx to it and if not present, it keeps clearing the active playlist ?

plman.ClearPlaylist(playlist_idx)

WSH Panel Mod

Reply #1669 –
i've added it but playlistIndex is going to be compulsory. the readme/docs will explain why it's different from fb.ClearPlaylist which is simply a shortcut to the Edit menu>Clear. i'll post an updated component later.

WSH Panel Mod

Reply #1670 –
Code: [Select]
v1.6.1 Beta 4
- ADD: window.CreateToolTip now takes optional font name and font size (px)
       arguments. eg window.CreateToolTip("Segoe UI", 32);
       Defaults of "Segoe UI" and 16 are used if omitted.
- ADD: plman.GetQueryItems(source_handlelist, query) returns an unsorted
       handle list. Consider using OrderByFormat, etc on the result
- ADD: plman.CreateAutoplaylist, plman.IsAutoPlaylist
       These behave the same as the "fb" methods which already exist.
- ADD: plman.ClearPlaylist(playlistIndex). Unlike fb.ClearPlaylist which
       clears the active playlist, this requires a "playlistIndex"
       argument.
- CHG: "Safe mode" is no longer an option.
- CHG: Tidy up samples.


https://github.com/19379/foo_uie_wsh_panel_mod/releases

WSH Panel Mod

Reply #1672 –
Thanks for the new methods.

I have done initial tests on the following.

  • plman.GetQueryItems(source_handlelist,  query). This is blazingly fast and definitely a good addition. Takes ~ 16 msec on 25K library for standard queries.
  • window.CreateToolTip(font.name, font.size).  This works perfectly satisfactorily for my needs as is. However, I did spot a  couple of things. Firstly, the font size was too small & smaller than the corresponding  DUI list font. I suspect that it's not handling the dpi setting the same way as the list font, since  the desktop scaling was 125%. This was easily corrected in my case by  multiplying the tooltip font.size by 1.25. The issue also occurs when a font.name and font.size are not specified. Secondly, if window.CreateToolTip(gdi.Font(name, size, style)) was  used, then the font style of tooltips can be set to enabling full  mimicking of other components like DUI albumlist, e.g. bold tooltips. Anyway I  only use the normal style so it's OK for me like it is.

WSH Panel Mod

Reply #1673 –
i suspect you didn't notice the part in bold...

Quote
- ADD: window.CreateToolTip now takes optional font name and font size (px)
      arguments. eg window.CreateToolTip("Segoe UI", 32);
      Defaults of "Segoe UI" and 16 are used if omitted.


this is actually the same as the gdi.Font function built into the component and why there has always been a Point2Pixel function inside docs\helpers.txt

Code: [Select]
// Convert Point size to Pixel size (Useful in gdi.Font() and such)
function Point2Pixel(pt, dpi) {
    return (pt * dpi / 72);
}


you'd pass 96 as the DPI when at 100% and 120 at 125%.

as for passing a font object to the function... that was the first thing i tried but i failed miserably which is why you have to use plain text and a number. 

WSH Panel Mod

Reply #1674 –
Quote from: marc2003 on
...is actually the same as the gdi.Font function built into the component


So I double-checked that the same variable is used for both the gdi.Font size and tooltip font size, which your quote says should yield the same size for text and tooltip display.

The picture shows the smaller size of the tooltip font on the right (desktop scaling was 125%); i.e. gdi.Font and the tooltip give a different size when given the same number as the font size.




The code that generated it is here.

Code: [Select]
var font_size = 200; // large font used for illustrative purposes
var g_font = gdi.Font("Segoe UI", font_size, 0);
var g_tooltip = window.CreateTooltip("Segoe UI", font_size);
fb.trace(font_size);
var text = "llllllllllllllllllllllllllll"
g_tooltip.Text = text;
g_tooltip.Activate();
g_tooltip.TrackPosition(50, 0);
function on_paint(gr) {
    gr.GdiDrawText(text, g_font, RGB(0,0,0), 0,40, 300, 300);
}

function RGB(r, g, b) {
return (0xff000000|(r<<16)|(g<<8)|(b)); 
}