Re: Finally have cleared the leaks ...

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---559023410-1849998704-1584991944=:19783
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Sun, 22 Mar 2020, 10bxjfhf wrote:
>> 
>> I have not yet re-implemented the logging formatting code such that the 
>> format set by the user is used for all cases.  Currently the user-specified

I have now implemented consistent logging formatting code which obeys 
the user.

> I have played with it a bit and compiled the latest libraries. Preliminary 
> comments:
>
> SetLogDefaultFileName( swLogFile );
>
> IMO would be useful to return the current log file string for display in 
> About as feedback
> also would allow splitting out some specific log info for a section of 
> code/function and restoring the default at a later time.

That seems useful.  For other areas, the command-line supports the 
-list option which prints out a summary to a file descriptor.  This is 
not the same as accessor functions but it seems like the logging 
configuration should be included as a supported option.

> I am wondering about the different usages of std::string and std::wstring. 
> For wxWidgets, everything is/needs to be converted to wide strings and when 
> calling the underlying Win API functions, I typically need to ensure to pass 
> wide strings.  Is this handled by GM * Magick++

Magick++ and GraphicsMagick (being very old software started in 
perhaps 1990) do not support wide strings.  The only way things work 
is if 7 or 8 bit string data is expressed in the same code-page as the 
filesystem, or if Unicode is represented in UTF-8, which then needs to 
be supported as such by the filesystem.  There is an existing problem 
report that GraphicsMagick on Windows is not able to open some UTF-8 
filenames containing Chinese characters.  Different operating systems 
have different capabilities and behavior when it comes to file names.

Even wide-character support does not assure correct 
support for internationalization because there is no assurance that 
there is not a mis-match.  ANSI C introduced wide characters in 1989 
before standards had evolved for how internationalization should be 
done.

>
> This initially came up with:
>
> wxString wsLogFileName = wfnLogFile.GetFullPath();
>   std::string sLogFile = wsLogFileName.ToStdString( );
>   SetLogDefaultFileName( sLogFile );
>
> So far I have not been able to set my own file name & path from within the 
> app.
>
> 2 things seems to get in the way and I have not been able to untangle all of 
> the interconnected issues.
>
> For Windows app with GM code linked as DLLs, all of the initialization is 
> done when the OS first decides it needs the CORE_xx_magick_.dll

Remember, this is configurable.  Given the problems that it is 
apparently causing, ProvideDllMain is no longer the default.

In the mean time, this sequence should work:

InitializeMagick(NULL);
DestroyMagick();
  [ Do some defaults configuration ]
InitializeMagick(NULL);

> MAGICK_CONFIGURE_PATH seems to have to be  undefined or blank, but undefining 
> or keeping MAGICK_HOME blank causes issues because delegates.mgk is not 
> found.

If you put the .mgk files in the same directory as the DLL, they 
should be found.  For a static build, it would be best to put the .mgk 
files in the same directory as the program.  Unix-type systems work 
much differently.

> I am considering linking the libs statically, though I am unsure whether it 
> will help. I would expect the OS to still get its turn before me and the only 
> way I see is to force a reload of the libraries or the DLLs at a point of my 
> choosing.

In this case there would be no DLL initialization so the OS would not 
get its turn.  You would be totally in control, but your program would 
appear much larger.

> FWIW, from here it looks as though the call to InitializeMagick from within 
> the app needs to override all data for the specific function the call is 
> expected to affect. At present, this does not happen for at least 
> SetLogDefaultFileName()

See my text above.

Please pull the latest changes and see if you are more satisfied.

Bob
-- 
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt
---559023410-1849998704-1584991944=:19783
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


---559023410-1849998704-1584991944=:19783
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Graphicsmagick-apis mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/graphicsmagick-apis

---559023410-1849998704-1584991944=:19783--