Skip to main content
Topic: fb2k API questions (Read 1606 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

fb2k API questions

@Peter , could you help with the following, please?

1. playlist_manager_v4::create_playlist_ex / playlist_manager_v4::create_playlist_ex: in which case can it return pfc_infinite? Is it more like paranoia check (i.e. assert would suffice) or should I always validate it?
2. What is assigned to the return value of playlist_manager::playlist_insert_items? Is it the new position of the first track (i.e. same as p_base argument)?
3. Is there any difference between using u* methods from shared.dll and using corresponding WinAPI methods? E.g. uCreateFile vs CreateFile

Thanks in advance =)

Re: fb2k API questions

Reply #1
1.
Playlist creation will fail if called from an illegal context - wrong thread, called from a global callback, fb2k shutdown in progress.
If your code already ensures running in main thread, an assert check should be sufficient.
You cannot call any methods that alter the state of playback, playlist, etc from a global callback - such as playlist/playback/etc callback - because the method by itself dispatches callbacks, which cannot be done recursively.
2.
Returned value from playlist_insert_items is the index of the first inserted track - or pfc_infinite on failure (conditions above or an autoplaylist that refuses insertions).
3.
u* methods used to be relevant when Win9X was still supported - Win9X users got a different build of the DLL which called non-Unicode APIs. By now there's no difference. These methods are mainly retained for backwards compatibility. Though you can sometimes reduce the size of your component by calling them instead of converting UTF-8 to wchar_t by yourself.

Re: fb2k API questions

Reply #2
Thanks!

1.
Playlist creation will fail if called from an illegal context - ... fb2k shutdown in progress ...
Am I right to assume that this condition won't be triggered until after initquit::on_quit callback is executed?

And another small question:
Can autoplaylist_manager::add_client_simple(p_query, p_sort, p_playlist, p_flags) fail on a newly created playlist?

Re: fb2k API questions

Reply #3
If your component creates playlist in direct response to user events, it is safe to assume that shutdown is not yet in progress.
initquit::on_quit() is one way to know about shutdown in progress, but if some other component decides to do stuff that triggers your code in their on_quit(), your on_quit() might not yet have executed.

autoplaylist_manager::add_client_simple() on a newly created playlist should never fail. The current implementation throws an exception if the specified playlist index is invalid, or if the playlist is already an autoplaylist, neither of which can be true in your case.




Re: fb2k API questions

Reply #7
Everything modal dialog related should only ever be called from main thread.

modal_dialog_scope::can_create() returns false when either called from a non main thread or there already is a known modal dialog running.


Re: fb2k API questions

Reply #9
@Peter, another small API question =)
What's the purpose of modal_dialog_scope? Is it purely a FYI method (i.e. indication that it would be possible to create a modal dialog)? Is it safe to invoke a modal dialog without wrapping it's call in modal_dialog_scope?

Re: fb2k API questions

Reply #10
And another question: what is the correct way for a component to generate a dynamic main menu (i.e. so that it could be changed after component initialization)? There is such menu for playlists ('View>Switch to playlist'), but I'm not sure how to achieve that....

I've found 'mainmenu_commands_v2' which might be what I need: there is a `mainmenu_commands_v2::dynamic_execute` method which accepts subId GUID, but should this GUID be distinct from all the other menu GUIDs? If so, then should I run a check against already defined GUIDs every time I add a new menu item?

Re: fb2k API questions

Reply #11
modal_dialog_scope exists to prevent accidental creation of another modal dialog while a modal dialog is already in progress. Execution of various fb2k menu commands is not blocked during a modal dialog, but you can at least know that there's a modal dialog in progress and refuse to create another one - which could lead to modal dialogs getting dismissed out of order or worse.

Dynamic mainmenu commands will be added to foo_sample.

Re: fb2k API questions

Reply #12
Thanks for the answers!

modal_dialog_scope exists to prevent accidental creation of another modal dialog while a modal dialog is already in progress. Execution of various fb2k menu commands is not blocked during a modal dialog, but you can at least know that there's a modal dialog in progress and refuse to create another one - which could lead to modal dialogs getting dismissed out of order or worse.
Hm... So that means that it is actually *required* for the component to wrap every modal dialog creation call. I think it would be nice to add this to 'modal_dialog_scope' documentation =)

Dynamic mainmenu commands will be added to foo_sample.
Thanks!


Re: fb2k API questions

Reply #14
@Peter: another question, if you don't mind =) What is the proper way to execute API action that requires initialized fb2k?

Example scenario #1: I want to show popup via `popup_message::g_show` during CUI panel creation (which happens before component's `on_init` is called). If invoked before fb2k is initialized, no popup will show up.

Example scenario #2: invocation timing is the same as above, but I need fb2k handle (via `core_api::get_main_window()`). This handle will be nullptr if requested before fb2k initialization.

Current workaround: queue all required action and execute them in the component's `on_init` callback.
Other workaround: queue actions via `fb2k::inMainThread` (this uses message queue probably, which activates only after fb2k initialization).

PS: The question above is still relevant =)

 
SimplePortal 1.0.0 RC1 © 2008-2019