Re: GM - more questions

  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-2023527218-1582294635=:19783
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Thu, 20 Feb 2020, 10bxjfhf wrote:

> On 2020-02-20 3:44 p.m., Bob Friesenhahn wrote:
>> On Thu, 20 Feb 2020, 10bxjfhf wrote:
>>> I had expected some output as well, but have not been able to find any.
>>> As I am not building & using a command line utility, all of my debug 
>>> output is being redirected to a log text window, but I see nothing from 
>>> the GM code other than the exception which I eventually decoded and spit 
>>> out.
>> 
>> If it is actually using code from the release, then there could be a 
>> problem due to varying Visual Studio versions.  Try editing the installed 
>> log.mgk to change the default destination.
> After looking at all of the log.mgk file I found, it looks like the only 
> thing these specify is the log file naming format. Nothing I could find about 
> where this file might end up(presumably close to the project root or some 
> temp directory) but I could not find a trace of any such named files anywhere 
> on the PC

As mentioned, the log is likely being sent to the Windows Application 
Event log.  This requires using an application to look at.  I hate the 
Windows Application Event log but it is the equivalent of textual log 
files on Unix-like systems.

The documentation for log.mgk is included in the file.  The "output" 
action says where to send it to (e.g. "win32eventlog") and if the 
output action is "txtfile" then "filename" may be used to send output 
to a file with the specified name.

The logging defaults established by InitializeLogInfo() assure that 
logging is reasonably sane before a log.mgk has been loaded.

> Right now it complains:
>
> Description: 
> "D:\pkg\wx\MSVC2019\_3.1.2_2019\wxIC-MT\DebUniStat\IM_MOD_DB_TIFF_.dll: The 
> specified module could not be found.
>
> ", Reason: Unable to load module,

This must be why the person who originally created the project files 
did things the way he did.  Everything is much easier if the 
executable and other involved files are in the same directory ('bin').

> Then of course, there is the choice of either using magick or magick++

I sense your frustration.  If you are comfortable with C++, Magick++ 
is definitely easier to pick up than the C API.  Magick++ does require 
using STL containers to read multiple frames from an image file 
though.  The C linked lists and STL containers did not seem like a 
good match, so I made it so that the C linked lists were converted 
into STL vectors, lists, or similar containers.

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-2023527218-1582294635=:19783
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


---559023410-2023527218-1582294635=: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-2023527218-1582294635=:19783--