Yep, I caught that. I had also added it to rexxc.exe because I didn't
understand what it was for. That one can be removed.
Btw, I see ooDialog has a .exe file and a .com file. I think I've got
those building correctly, but I'm not sure I understand what the .com file
is for. I'm also adding the manifest to that one.
Rick
On Wed, May 21, 2014 at 5:35 PM, Mark Miesfeld <miesf...@gmail.com> wrote:
> On Wed, May 21, 2014 at 2:29 PM, Rick McGuire <object.r...@gmail.com>wrote:
>
>> Mark,
>>
>> Thanks for the answer. I did find a solution for this. It turns out to
>> possible to replace or merge additional manifest information into the
>> executables as a post-processing step. I wasn't really sure which .exe
>> files needed this, so I end up merging it into them all. If only ooDialog
>> needs this, then that can simplify things in the cmake file considerably
>> since I had to add a lot of WIN32 conditional stuff to do this.
>>
>
> It is actually all the executables that would run an ooDialog program.
> So, rexx.exe, rexxhide.exe, rexxpaws.exe and oodialog.exe need the
> manifest. With the common controls dependency part I posted.
>
> --
> Mark Miesfeld
>
>
>
>>
>> Rick
>>
>>
>> On Wed, May 21, 2014 at 5:17 PM, Mark Miesfeld <miesf...@gmail.com>wrote:
>>
>>> Hi Rick,
>>>
>>> I'm still traveling and only have good Internet once in awhile. So
>>> I've put off answering this. But thought I'd better do something about it.
>>>
>>> The existing manifest was only needed for ooDialog. The important part
>>> is the part to load the 6.0 common controls library:
>>>
>>> <description>Open Object Rexx Interpreter.</description>
>>> <dependency>
>>> <dependentAssembly>
>>> <assemblyIdentity
>>> type="win32"
>>> name="Microsoft.Windows.Common-Controls"
>>> version="6.0.0.0"
>>> processorArchitecture="amd64"
>>> publicKeyToken="6595b64144ccf1df"
>>> language="*"
>>> />
>>> </dependentAssembly>
>>> </dependency>
>>>
>>> Since that is needed by any Windows GUI application to use the 6.0, or
>>> later, version of the library, it seems odd to me that CMake wouldn't have
>>> a way to do it, if it is generating its own manifest. Without it, the
>>> pre-verison 6.0 is loaded automatically, which is essentially W2K controls.
>>>
>>> It took me quite a bit of work to get it working originally. It needs
>>> to be the manifest of the executable that loads the ooDialog extension,
>>> which I didn't understand when I first started with it. I thought it was
>>> sufficient to use it for ooDialog.dll.
>>>
>>> So, if we can't get CMake to add the common controls part to the
>>> manifest it generates, then I'll have to add the custom step. I won't be
>>> back at home until after Memorial day. I'll work on it then if you haven't
>>> already come up with something.
>>>
>>> --
>>> Mark Miesfeld
>>>
>>>
>>>
>>> On Mon, May 5, 2014 at 4:17 AM, Rick McGuire <object.r...@gmail.com>wrote:
>>>
>>>> This is mostly to get this question recorded for Mark for when he gets
>>>> back from vacation.
>>>>
>>>> I'm currently running into some issues with the manifest file we're
>>>> embedding in rexx.exe via an include within rexx.rc. Building this via
>>>> this method causes a duplicate resource error because the cmake build tools
>>>> generate a default manifest which gets embedded via the /MANIFEST and
>>>> /MANIFESTFILE linker options. When the .rc file pulls in the second
>>>> manifest, this creates the error.
>>>>
>>>> For now, I've commented out the link in rexx.rc that pulls in the
>>>> manifest file, so the cmake build is using the one it generates. For the
>>>> existing build, I've switched to rexx.mak file to use /MANIFEST and
>>>> /MANIFESTFILE link options. We're going to run into this same issue with
>>>> the oodialog executables when we get that portion working in cmake as well.
>>>> I really don't understand the manifests and what information needs to be
>>>> in there. The cmake-generated manifests and the ones we are using are
>>>> quite different. Here is our version:
>>>>
>>>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
>>>> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
>>>> <assemblyIdentity
>>>> version="1.0.0.0"
>>>> processorArchitecture="amd64"
>>>> name="RexxLA.ooRexx.rexx"
>>>> type="win32"
>>>> />
>>>> <description>Open Object Rexx Interpreter.</description>
>>>> <dependency>
>>>> <dependentAssembly>
>>>> <assemblyIdentity
>>>> type="win32"
>>>> name="Microsoft.Windows.Common-Controls"
>>>> version="6.0.0.0"
>>>> processorArchitecture="amd64"
>>>> publicKeyToken="6595b64144ccf1df"
>>>> language="*"
>>>> />
>>>> </dependentAssembly>
>>>> </dependency>
>>>> </assembly>
>>>>
>>>>
>>>> and here is the cmake version:
>>>>
>>>>
>>>> <?xml version='1.0' encoding='UTF-8' standalone='yes'?>
>>>> <assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
>>>> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
>>>> <security>
>>>> <requestedPrivileges>
>>>> <requestedExecutionLevel level='asInvoker' uiAccess='false' />
>>>> </requestedPrivileges>
>>>> </security>
>>>> </trustInfo>
>>>> </assembly>
>>>>
>>>> Note that cmake generates one of these for all of the dlls and exes.
>>>>
>>>>
>>>> So, do we need to continue using our manifest version or can just allow
>>>> the cmake defaults? Does the cmake version cause any problems with the
>>>> other files? I've found information on how to use custom manifests, which
>>>> involves disabling the automatic generation and then adding a
>>>> post-processing step that uses a tool to add the custom manifest. A bit
>>>> of a pain, but doable. I think I'd prefer to let cmake do the heavy
>>>> lifting if we can.
>>>>
>>>>
>>>> Rick
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Is your legacy SCM system holding you back? Join Perforce May 7 to find
>>>> out:
>>>> • 3 signs your SCM is hindering your productivity
>>>> • Requirements for releasing software faster
>>>> • Expert tips and advice for migrating your SCM now
>>>> http://p.sf.net/sfu/perforce
>>>> _______________________________________________
>>>> Oorexx-devel mailing list
>>>> Oorexx-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>>> Instantly run your Selenium tests across 300+ browser/OS combos.
>>> Get unparalleled scalability from the best Selenium testing platform
>>> available
>>> Simple to use. Nothing to install. Get started now for free."
>>> http://p.sf.net/sfu/SauceLabs
>>>
>>> _______________________________________________
>>> Oorexx-devel mailing list
>>> Oorexx-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos.
>> Get unparalleled scalability from the best Selenium testing platform
>> available
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>> _______________________________________________
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
