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: New SDK with foobar2000 v2.0 features released (2022-08-10) (Read 11655 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: New SDK with foobar2000 v2.0 features released (2022-08-10)

Reply #50
I'm having an issue where using cfg_window_placement_v2 is causing crashes on shutdown.

It works perfectly fine when the target version is 81 for fb2k v2 only. It seems to be problematic if the target version is set to 80 for compatibility with fb2k v1. Using the latest 2022-11-16.

Code: [Select]
class CDialogBlah : public CDialogImpl<CDialogReport>, public cfg_window_placement_v2
{
public:
CDialogBlah() : cfg_window_placement_v2(guids::window_placement) {}

BEGIN_MSG_MAP_EX(CDialogBlah)
MSG_WM_INITDIALOG(OnInitDialog)
COMMAND_ID_HANDLER_EX(IDCANCEL, OnCancel)
END_MSG_MAP()

enum { IDD = IDD_DIALOG_BLAH };

BOOL OnInitDialog(CWindow, LPARAM)
{
apply_to_window(*this, false);
return TRUE;
}

void OnCancel(uint32_t, int nID, CWindow)
{
read_from_window(*this);
EndDialog(nID);
}
};

Crash report is pointing here...


Re: New SDK with foobar2000 v2.0 features released (2022-08-10)

Reply #51
Documentation error, should make it more clear how this class works.
Basically, do not derive from cfg_window_placement.
It's a cfg_var class meant for static objects.
Just have a static instance and use it from your dialog object.
What you did works by accident in new fb2k config system but wasn't really meant to.
We are the bork. Your software bugs will be added to our own. Resistance is futile.


Re: New SDK with foobar2000 v2.0 features released (2022-08-10)

Reply #53
Re listview dark mode,

My implementation of this is even crazier than the rest of dark mode stuff -
MS listview outright defies proper darkening, so instead of rewriting every use case to use something else, I wrote a wrapper to drop CListControl in place of each one... and make it interop with listview API. So, issues are to be expected. I just had to add basic custom draw support to it because spectrogram colors dialog needed it.

I've got a listview with multiple columns. The list gets populated using ListView_InsertItem and ListView_SetItemText. When dark mode has been applied, it won't show the text that was added using ListView_SetItemText. Any chance for a fix?

Re: New SDK with foobar2000 v2.0 features released (2022-08-10)

Reply #54
@Peter  I've got a component that adds a search to an autoplaylist and does:
Code: [Select]
apm->add_client_simple(param1.toString(), cfg.query.sortpattern, playlist, autoplaylist_flag_sort);
// force sort so results are always returned sorted, and then clear so user can reorder if needed
apm->set_client_flags(playlist, 0);
This works <2.0 because the search isn't async, but now that it is, the force_sort flag is cleared before any results are returned. Is there a way to make it wait for the autoplaylist search/update to finish?

Re: New SDK with foobar2000 v2.0 features released (2022-08-10)

Reply #55
 cfg.query.sortpattern infers you have a preference for the sort pattern. Add a new force sort checkbox next to and you don't need to change the flags.

Re: New SDK with foobar2000 v2.0 features released (2022-08-10)

Reply #56
cfg.query.sortpattern infers you have a preference for the sort pattern. Add a new force sort checkbox next to and you don't need to change the flags.
Yeah, that's probably a better idea.

On an unrelated issue, I've been trying to update to using the latest SDK and rebuild some of my old components. I was able to get everything working for x32, but completely stymied on x64. Getting dozens of these errors:
error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MDd_DynamicDebug' doesn't match value 'MTd_StaticDebug' in contextmenu.obj

It goes away if I change the configuration type of the main component to static lib, but obviously that's not useful when trying to create .dll components. I've double checked the settings of all the required SDK components, with another component (not of mine) that does build in x64 and they're identical. All of the SDK projects build static libs, and then the component builds a DLL without the linker complaining at all. No idea what I could possibly be missing, and why I can easily build a .dll in x86 but not x64 with seemingly identical settings.

Re: New SDK with foobar2000 v2.0 features released (2022-08-10)

Reply #57
Double check your settings under the properties page>C/C++/Code Generation

Make sure the configuration is Release and platform combo box is set to all platforms because you want the same for 32bit/64bit.

Then check Runtime Library and make sure it's Multi-Threaded DLL (/MD). This corresponds with the default settings of the current SDK.

edit: also double check the configuration manager and make sure the platform for all projects matches the solution platform.

edit2: not sure how much it matters but you should also check your PFC project is Release FB2K and not just Release here...







Re: New SDK with foobar2000 v2.0 features released (2022-08-10)

Reply #58
Make sure the configuration is Release and platform combo box is set to all platforms because you want the same for 32bit/64bit.

Then check Runtime Library and make sure it's Multi-Threaded DLL (/MD). This corresponds with the default settings of the current SDK.
THANK YOU! Somehow I had checked every dependency and they were all correct, but the main component was set to Multi-Threaded and not Multi-Threaded DLL. I swear I checked every property multiple times and somehow missed that one. Building perfectly in x64 now. I owe you a beer. :)

Re: New SDK with foobar2000 v2.0 features released (2022-08-10)

Reply #59
@Peter, I think there's a bug with get_sort_priority in contextmenu_item_lambda . It should return m_sortPriority but currently returns 0.



Re: New SDK with foobar2000 v2.0 features released (2022-08-10)

Reply #61
I'd like to request the ability to bulk add playlist queue items. It seems the only way to re-order the current queue or insert new items at a given point is to flush the queue and then add them back one at a time which triggers the callback more than is necessary. If I missed a way to do this, I'll take any pointers.

Re: New SDK with foobar2000 v2.0 features released (2022-08-10)

Reply #62
I updated to the latest SDK and now I'm seeing weird NuGet errors:
Code: [Select]
1>D:\Source\foo_httpcontrol\foo_httpcontrol\lib\foobar2000\helpers\foobar2000_sdk_helpers.vcxproj(607,5): error : 
This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is ..\packages\wtl.10.0.10320\build\native\wtl.targets.
and same for LibPPUI. If I do NuGet Package Restore though on the solution, I get "All packages are already installed and there is nothing to restore."

It feels like the relative path is wrong, but I'm not sure what it's relative to. If I delete the packages folder in the project and rerun NuGet restore it gets added back so it definitely thinks it goes there.

Edit: Nevermind, it was the relative paths from the SDK projects. They'd originally been altered but overwriting the SDK caused those changes to get screwed up. All working now.

Re: New SDK with foobar2000 v2.0 features released (2022-08-10)

Reply #63
2023-05-10 SDK, small typo:
SDK/library_callbacks.h: 18 :
`cycle called due to actual tags changed or dispaly hook operations?`

Re: New SDK with foobar2000 v2.0 features released (2022-08-10)

Reply #64
What's the difference between `inWorkerThread` and `inCpuWorkerThread` in SDK 2023-05-10/SDK/threadPool.h?

Re: New SDK with foobar2000 v2.0 features released (2022-08-10)

Reply #65
I've got a listview with multiple columns. The list gets populated using ListView_InsertItem and ListView_SetItemText. When dark mode has been applied, it won't show the text that was added using ListView_SetItemText. Any chance for a fix?

I'm attaching a sample project built using the latest SDK that demonstrates this issue. All the relevant code is located in CMyPreferences::OnInitDialog

Re: New SDK with foobar2000 v2.0 features released (2022-08-10)

Reply #66
Implementing list views with libPPUI ensures dark mode works. Look at the three files prefixed with listcontrol in the foo_sample folder.

BTW, you typically want m_hooks.AddDialogWithControls(*this); as the last line before the return statement in your OnInitDialog.

Re: New SDK with foobar2000 v2.0 features released (2022-08-10)

Reply #67
Implementing list views with libPPUI ensures dark mode works. Look at the three files prefixed with listcontrol in the foo_sample folder.
Thanks, I'll check that out!

Quote
BTW, you typically want m_hooks.AddDialogWithControls(*this); as the last line before the return statement in your OnInitDialog.
That's the way it was in the official sample code. I also had problems putting that call at the end of the function, because it would re-create some controls that I had previously initialized.

Re: New SDK with foobar2000 v2.0 features released (2022-08-10)

Reply #68
Well here's a real world example from one of my components...



I've attached the source code. It contains 2 list control instanaces (one CListControlSimple, one CListControlOwnerData).


Re: New SDK with foobar2000 v2.0 features released (2022-08-10)

Reply #69
Well here's a real world example from one of my components...

Thanks! Switching to CListControlSimple was actually very straightforward  :)

Re: New SDK with foobar2000 v2.0 features released (2022-08-10)

Reply #70
@Peter I've tried using built-in thread pool and encountered a weird behaviour: it seems that thread is not initialized with `CoInitialize` on creation and `CoInitialize` is invoked only later on. This means that COM calls can't be used in worker threads reliably.

Problem is, only thread owner knows arguments for CoInitialize (and must call CoUninitialize before thread destruction as well), so it shouldn't be called by thread user (unless they want to risk breaking the rest of fb2k).

Could you add CoInitialize during worker thread creation to prevent this issue?

Re: New SDK with foobar2000 v2.0 features released (2022-08-10)

Reply #71
You should call CoInitialize() + CoUninitialize() yourself if you need COM. As far as I can see, everything in my code matches CoInitialize() with CoUninitialize(), so you worker thread clients should always assume that COM hasn't been initialized on entry.

If I change it now and you rely on prior COM init, your code no longer works under foobar2000 v2.0, so you need a workaround on your side anyway.
We are the bork. Your software bugs will be added to our own. Resistance is futile.

Re: New SDK with foobar2000 v2.0 features released (2022-08-10)

Reply #72
You should call CoInitialize() + CoUninitialize() yourself if you need COM. As far as I can see, everything in my code matches CoInitialize() with CoUninitialize(), so you worker thread clients should always assume that COM hasn't been initialized on entry.
Oh, you mean CoInitialize() + CoUninitialize() in the task? Right, that works, thanks :)
But, still, it seems that some fb2k tasks are 'leaking', because otherwise my tasks (without explicit CoInitialize) should've always failed, but they work after GUI is fully initialized. This is reliably reproduceable on latest non-preview version of fb2k with zero 3rd-party components installed (except for mine, of course).


Re: New SDK with foobar2000 v2.0 features released (2022-08-10)

Reply #74
You learn something new every day... Thanks!