-
Notifications
You must be signed in to change notification settings - Fork 798
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plugin for FILE_PACK_UNPACK cannot store persistent data #2343
Comments
As shown below, I tried storing 1234 in the m_data member variable using the UnpackFile function of the DisplayXMLFiles plugin in the WinMerge repository, and referencing it with the PackFile function, but 1234 was stored. In other words, the m_data member variable remained without being released, and the problem could not be reproduced.
|
@sdottaka I agree that storing a single value works correctly whether as a member variable as you demonstrated or through the pSubcode parameter. The issue I am having is: how to determine the original source file of the file being packed. In my example below, the source file name is saved but when the Left file is changed the source file name has already been replaced by that of the Right file.
In my first comment I mentioned using pSubcode as an id, which works to uniquely identify the correct meta data when packing. Your code helped me understand that the CWinMergeScript is persistent, so I added a destructor to see if I could reference count the objects... My original code used InternalFinalConstructAddRef() and InternalFinalConstructRelease() to perform reference counting, but I think using the CWinMergeScript constructor and destructor could work! There are 2 objects being instantiated, 1 is destroyed when I close the comparison window and 1 is destroyed when I close the Select Files dialog. I'll do some more testing to make sure the objects are never destroyed while in-use but I think this has solved my problem. I do suggest providing access to the original source file path in PackFile() but it looks like I have a workaround :) Thank you for your help! Arigato gozaimasu |
Ultimately, the workaround still has an issue. I'm not sure why, but WinMerge always uses the first instance of the plugin object no matter how many times I open and close tabs within the application. Here is a brief log to demonstrate what I mean:
I'm glad I can just use the object destructor to cleanup memory I allocate for storing the original unpacked paths, but it does cause some limitations on when I can free memory that is no longer in use. I wish I had time to fork the repo and look into how the plugin is invoked. I suggest closing this issue for now and maybe just plan to enhance plugin support in the future. |
An instance of the plugin is created for each WinMerge thread, and is reused in the same thread. You can store meta data as follows:
|
That is essentially what I came up with as well 😄 |
Requests:
[] plugin remains in memory till the source file is closed
[] the PackFile() function has access to the original path of the source file
The PackFile() parameters include the source file from WinMerge and the desired final destination of the packed file. The file type I am trying to work with requires the original source file that was unpacked to access meta data that must be included in the newly packed file.
I tried to work around the problem by using pSubcode to store an id where the meta data could be stored in memory, but because the plugin is not persistent, InternalFinalConstructRelease() is called before the file is packed and therefore all of the meta data is lost.
My current implementation uses a global variable to store the meta data and just allows for a memory leak. It's not ideal, but it works.
The text was updated successfully, but these errors were encountered: