Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Allow Windows to search and load Icons and Cursors from VFS.#1781

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
RegDogg wants to merge4 commits intopanda3d:master
base:master
Choose a base branch
Loading
fromRegDogg:feature/curson_icon_vfs

Conversation

@RegDogg
Copy link
Contributor

@RegDoggRegDogg commentedNov 23, 2025
edited
Loading

Issue description

This change will allow Windows to search Multifiles mounted with VFS for icons and cursors

Solution description

By utilizing functionsLookupIconIdFromDirectoryEx andCreateIconFromResourceEx we can read filedata in the VFS fromicon-filename/cursor-filename filepaths

Checklist

I have done my best to ensure that…

  • …I have familiarized myself with the CONTRIBUTING.md file
  • …this change follows the coding style and design patterns of the codebase
  • …I own the intellectual property rights to this code
  • …the intent of this change is clearly explained
  • …existing uses of the Panda3D API are not broken
  • …the changed code is adequately covered by the test suite, where possible.

@RegDogg
Copy link
ContributorAuthor

Finished, awaiting final review.

Copy link
Member

@rdbrdb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

This sounds like a useful feature to have, thanks for working on it! Comments inline.

// The filename doesn't exist along the search path.
if (resolved.is_fully_qualified() && resolved.exists()) {
// But it does exist locally, so accept it.
if ((resolved.resolve_filename(get_model_path())) || (resolved.is_fully_qualified() && resolved.exists())) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

It may still be in the VFS ifexists() returns true if there is an overlapping mount.

Here's how to get the system filename from a VFS filename:

PT(VirtualFile)vfile= ...;//checkvfileSubfileInfoinfo;if (vfile->get_system_info(info)&&info.get_start()==0) {Filenamefn=info.get_filename();//dosomethingwithfn.to_os_specific()

return (HICON)((*fi).second);
}

Filename os = resolved.to_os_specific();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

to_os_specific() returns anstd::string, not a Filename (as Filename is a container for OS-independent paths).

VirtualFileSystem *vfs =VirtualFileSystem::get_global_ptr();
PT(VirtualFile) vfile = vfs->get_file(filename);
if (vfile !=nullptr) {
std::string vfile_data = vfile->read_file(0);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

More idiomatic to use the vector_uchar version:

vector_uchar vfile_data;if (!vfile->read_file(vfile_data,false)) {// error handle}


int offset =LookupIconIdFromDirectoryEx((PBYTE)vfile_data.data(),TRUE,0,0, LR_DEFAULTCOLOR);
if (offset !=0) {
HICON hIcon =CreateIconFromResourceEx((PBYTE)vfile_data.data() + offset, fsize - offset,TRUE,0x30000,0,0, LR_DEFAULTCOLOR);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I'm wondering if there is a lifetime issue here. I haven't read the documentation, but does the icon created by CreateIconFromResourceEx copy the data passed in, or does it continue to refer to the same data in memory? If so, that might be an issue since thestd::string will be deallocated at the end of the function.

Secondly, you're passing in the remaining size of the whole data structure, not the size of the icon in it; is that okay?

std::string vfile_data = vfile->read_file(0);
long fsize = vfile_data.length();

int offset =LookupIconIdFromDirectoryEx((PBYTE)vfile_data.data(),TRUE,0,0, LR_DEFAULTCOLOR);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I'm really confused by this; the "icon id" that this function returns is actually a byte offset in some cases? Is that an undocumented feature of this call?

_cursor_filenames[resolved] = h;
return (HCURSOR)h;
HANDLE h =LoadImage(nullptr, os.c_str(),
IMAGE_CURSOR,0,0, LR_LOADFROMFILE);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

This is a lot of code to duplicate; is it conceivable to have the shared logic put in a private method that takes parameters as necessary to distinguish cursor from icon? It would do the actual loading but not the map storage/lookup.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@rdbrdbrdb left review comments

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@RegDogg@rdb

[8]ページ先頭

©2009-2025 Movatter.jp