xlw-users — For users of XLW, the C++ wrapper of Excel C API

[Xlw-users] Error C1047: The object or library file was created by a different version of the compiler

[Hahn B. <kar...@gm...>]

Hi all,

First, thank you very much for creating, sharing, and maintaining this
project. It got me up and running within a day with the daunting task of
exposing some C++ functionality to Excel. However, because xlw worked like
a charm out of the box, I invested a lot of time in adding (to my code) the
functionality I needed before trying to compile in *release* mode and
distributing my xll. When the dust settled from all the code writing, I
switched to release and I don't seem to be able to compile because of the
following error:

Severity Code Description Project File Line Suppression State
Error C1047 The object or library file
'C:\Users\pisaiah\Work\SwapCurvesProject\MarketMonitor\packages\xlw.20.8.16-DEVd0cc\native\lib\x64\xlw-vc142-mt-20_08_16.lib'
was created by a different version of the compiler than other objects like
'x64\Release\source.obj'; rebuild all objects and libraries with the same
compiler SwapCurveBootstrapping
C:\Users\pisaiah\Work\SwapCurvesProject\MarketMonitor\SwapCurveBootstrapping\LINK
1


To reiterate for clarity, everything works fine if I toggle the release
mode to debug mode.

Any suggestions, hints, or pointers in the right direction are highly
appreciated.

Thanks again for this great project.

Regards,
HB

[Xlw-users] Fw: xlw development

[Narinder C. <nar...@ya...>]

 

 Hi,
I am currently updating XLW and plan to release a nuget package soon.The development is taking place on github  xlw/xlw
My intention is to significantly simply the process of building an xll by simply requiring the user to add a nuget package to their project.I have however dropped all support for GCC and older Visual Studio versions.


| 
| 
| 
|  |  |

 |

 |
| 
|  | 
xlw/xlw

git repository for xlw - Excel xlls made easy. Contribute to xlw/xlw development by creating an account on GitHub.
 |

 |

 |





RegardsNarinder  

[Xlw-users] (no subject)

[Rizwan <maj...@gm...>]

Hi,

A calculation intensive C function is returning a very large negative
number in Excel. Problem in VBA was resolved with CDec( ).

Has anybody ran through with similar problem.

Regards.

[Xlw-users] CellValue abstract class error

[M H <mt...@ho...>]

Hi


I recently migrated to XLW5.  My code was compiling and working fine on XLW4.  I use VS 2008.  To migrate, I changed the linker library to version 5 library name.  That's about the only change I made.  Now i am getting error on the following code (this was working fine in v4).  I haven't changed the project code in the last 6-7 years so I apologize for basic errors as I am little rusty.

CellValue getValue(const unsigned long i, const CellMatrix &cm) {
int cols = cm.ColumnsInStructure();
unsigned long r = (i / cols);
unsigned long c = (i % cols);
CellValue cv = cm(r,c);
return cv;
}

I get a long list of similar compiler errors:

2>xlwWrapper.cpp
2>source.cpp
2>.\source\source.cpp(203) : error C2259: 'xlw::CellValue' : cannot instantiate abstract class
2>        due to following members:
2>        'bool xlw::CellValue::IsAString(void) const' : is abstract
2>        C:\Program Files (x86)\XLW\xlw-5.0.2f0\xlw\include\xlw/CellValue.h(37) : see declaration of 'xlw::CellValue::IsAString'
2>        'bool xlw::CellValue::IsAWstring(void) const' : is abstract
2>        C:\Program Files (x86)\XLW\xlw-5.0.2f0\xlw\include\xlw/CellValue.h(39) : see declaration of 'xlw::CellValue::IsAWstring'
2>        'bool xlw::CellValue::IsString(void) const' : is abstract
2>        C:\Program Files (x86)\XLW\xlw-5.0.2f0\xlw\include\xlw/CellValue.h(41) : see declaration of 'xlw::CellValue::IsString'
2>        'bool xlw::CellValue::IsANumber(void) const' : is abstract
2>        C:\Program Files (x86)\XLW\xlw-5.0.2f0\xlw\include\xlw/CellValue.h(42) : see declaration of 'xlw::CellValue::IsANumber'


2>.\source\source.cpp(3005) : error C3861: 'CellValue': identifier not found
2>.\source\source.cpp(3028) : error C2259: 'xlw::CellValue' : cannot instantiate abstract class


Thanks
Monty

[Xlw-users] Any issues with compiling against VC140 toolset?

[Nishank B. <nis...@gm...>]

Hi John/Team/Users,

I recently switched my code base which was building with the vc100 toolset
(VS2010) to the vc140 toolset( VS2015). Were any issues reported with
building XLW against this toolset? I dont see any build issues per se but
my program has been crashing from time to time with some Access Violation
Exceptions stemming from the XLW source. Seems to be happening with the
deep copy routines in the esharedptr class. Was anything like this
independently reported by users or found by you while testing?

I must say, I am running the code against XLW in a multi-threaded fashion
which begs the question, is the XLW code base thread safe? Or what
potential problems can I expect? Interestingly enough none of the issues I
face now seem to have been happening when I build against the older version
of the toolset and started appearing only after my upgrade to the new
toolset.

Please let me know if anything I am saying is something you have seen
before? I can give you some detailed error messages/crash dumps but was
just wondering if this is something that came up before.

Thanks,
Nishank.

Re: [Xlw-users] New Version

[John A. <jo...@th...>]

Matt

Sorry for not getting back.

I have no plans to do another release nor to extend xlw further, especially
for

The latest code is

https://sourceforge.net/p/xlw/code/HEAD/tree/branches/Dev6/xlw/

And that "should" work with any newer compilers although I haven't tested
it.

Please do send any reports or patches.

John

On 7 May 2018 at 11:09, Matthias Ruess <mr...@gm...> wrote:

> Hi,
> are there any plans to release a new version that is working out of the
> box with VS2017 by end of this year?
> Are there any plans to use some of the new c++11/14/17 features?
> What about using std::variant for cell values or std::optional to replace
> double or nothing?
>
> Cheers, Matt
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Xlw-users mailing list
> Xlw...@li...
> https://lists.sourceforge.net/lists/listinfo/xlw-users
>
>

[Xlw-users] New Version

[Matthias R. <mr...@gm...>]

Hi,
are there any plans to release a new version that is working out of the box
with VS2017 by end of this year?
Are there any plans to use some of the new c++11/14/17 features?
What about using std::variant for cell values or std::optional to replace
double or nothing?

Cheers, Matt

Re: [Xlw-users] Various Doubts (Compiler / 64 bit builds).

[John A. <jo...@th...>]

Hi Jayme

> Any specific version of XLW for these?
Use the trunk on svn

> I was used to build XLW addins with MS Visual Studio Express 2013, and I
just bought a new Windows 10 computer.
> Is it possible to build XLW addins wit MS Visual Studio Express 2017, as
2013 version is no longer available for download? Are projects compatible?
Should be fine to load up the most recent projects in 2017 and let it
convert with the trunk code

>   How should I configure the Compiler to be able build x64/64 bits
addins? Do I need any Windows 10 SDK?
Select x64 as the solution platform instead of Win32 and it will build
64bit.

let me know if there are any issues.

John


On 2 April 2018 at 16:11, Jayme Galvão de Oliveira Junior <
jay...@gm...> wrote:

> Hi Everybody,
>
>    I was used to build XLW addins with MS Visual Studio Express 2013, and
> I just bought a new Windows 10 computer.
>    Is it possible to build XLW addins wit MS Visual Studio Express 2017,
> as 2013 version is no longer available for download? Are projects
> compatible?
>    How should I configure the Compiler to be able build x64/64 bits
> addins? Do I need any Windows 10 SDK?
>    Any specific version of XLW for these?
>
>    Thanks, Regards,
>
> Jayme Galvão de Oliveira Jr.
>   +55 11 99917-7097 (Cel - SP Vivo)
>   +55 12 3942-7544
>
> A informação transmitida destina-se apenas à pessoa ou entidade a quem foi
> endereçada e pode conter informação confidencial, legalmente protegida e
> para conhecimento exclusivo do destinatário. Se o leitor desta advertência
> não for o seu destinatário, fica ciente de que sua leitura, divulgação,
> distribuição ou cópia é estritamente proibida. Caso a mensagem tenha sido
> recebida por engano, favor comunicar ao remetente e apagar o texto do
> computador.
>
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient is prohibited. If you received
> this in error, please contact the sender and delete the material from any
> computer.
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Xlw-users mailing list
> Xlw...@li...
> https://lists.sourceforge.net/lists/listinfo/xlw-users
>
>

Re: [Xlw-users] track version of XLL in the resource file in VS C++

[John A. <jo...@th...>]

Lu

You need to add a resource (.rc) file to the project with the version
information in it.

Right click on the project in the solution explorer, Add, New item, Then
from Visual C++, Resource add Resource File (.rc) calling it something
sensible.

Then in the new resource view tab, right click on the new resource folder
and add resource, Version.

You should then have the editor for all the properties that will appear
when you right click.

John


---------- Forwarded message ----------
From: Liu, Lu <Lu...@fi...>
Date: 8 August 2017 at 14:54
Subject: [Xlw-users] track version of XLL in the resource file in VS C++
To: "xlw...@li..." <xlw...@li...>


Hi,



I’ve been successfully built the XLL excel add-in and now I want to create
a resource .rc file to track the version of my XLL. However, it is not
working. For my other DLLs that I built in C++, I can see good values if I
right click on the DLL and go to properties->details. can anyone help?
Thanks!



Regards,

Lu


The information contained in this message is proprietary and/or
confidential. If you are not the intended recipient, please: (i) delete the
message and all copies; (ii) do not disclose, distribute or use the message
in any manner; and (iii) notify the sender immediately. In addition, please
be aware that any message addressed to our domain is subject to archiving
and review by persons other than the intended recipient. Thank you.

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Xlw-users mailing list
Xlw...@li...
https://lists.sourceforge.net/lists/listinfo/xlw-users

Re: [Xlw-users] Adding XLW functionality...?

[John A. <jo...@th...>]

And

I don't think there is a particularly good reason why the functionality was
never added.

The best I can do is to speculate that most of us work in corporate
environments where the adding of add-ins is done automatically and so we've
never needed it.

Feel free to add support for it, as far as testing is concerned there isn't
any automated testing but changes of the type you mention should be fairly
low risk.

John

On 29 November 2017 at 22:04, And Kemp <ap...@ua...> wrote:

> Hi,
>
> I'm looking to include a (single) welcome message upon adding an XLL into
> Excel.
>
> Test subjects have found receiving repeated messages from xlAutoOpen upon
> every Excel startup to be annoying.
>
> I've taken a look at the XLW source code and believe any modifications to
> introduce this feature to be found within files
> XlOpenClose.h
> xlw.h
>
> Discretion being the better part of valour, I have noticed that there is
> working undocumented functionality for xlAutoRemove within the code.
>
> Before I start meddling, could someone please advise me as to why
> xlAutoAdd wasn't incorporated into XLW? If there are development notes
> available other than the summary at
> http://xlw.sourceforge.net/history.shtml
> I would be glad to learn so that I can read those please.
>
> Similarly, any links or advice regarding thorough testing for any
> modifications to XLW code would be greatly appreciated.
>
> I spent many unhappy hours unsuccessfully trying to get my XLL to work for
> both 32-bit and 64-bit versions of Excel using the MS XLL SDK and advice
> from Steve Dalton's excellent book before success using XLW. I really don't
> want to start experimenting with stable library code if there's a good
> reason I shouldn't even consider it in the first place!
>
> Thanks for reading and best wishes,
>
> And.
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Xlw-users mailing list
> Xlw...@li...
> https://lists.sourceforge.net/lists/listinfo/xlw-users
>
>

[Xlw-users] Various Doubts (Compiler / 64 bit builds).

[Jayme G. de O. J. <jay...@gm...>]

Hi Everybody,

   I was used to build XLW addins with MS Visual Studio Express 2013, and I
just bought a new Windows 10 computer.
   Is it possible to build XLW addins wit MS Visual Studio Express 2017, as
2013 version is no longer available for download? Are projects compatible?
   How should I configure the Compiler to be able build x64/64 bits addins?
Do I need any Windows 10 SDK?
   Any specific version of XLW for these?

   Thanks, Regards,

Jayme Galvão de Oliveira Jr.
  +55 11 99917-7097 (Cel - SP Vivo)
  +55 12 3942-7544

A informação transmitida destina-se apenas à pessoa ou entidade a quem foi
endereçada e pode conter informação confidencial, legalmente protegida e
para conhecimento exclusivo do destinatário. Se o leitor desta advertência
não for o seu destinatário, fica ciente de que sua leitura, divulgação,
distribuição ou cópia é estritamente proibida. Caso a mensagem tenha sido
recebida por engano, favor comunicar ao remetente e apagar o texto do
computador.

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.

[Xlw-users] two cell matices and multiple arguments example

[Rizwan <maj...@gm...>]

Hi,

 

Does anybody has a two cell matices and multiple arguments xlw example?

 

Thanks.

[Xlw-users] Adding XLW functionality...?

[And K. <ap...@ua...>]

Hi,

I'm looking to include a (single) welcome message upon adding an XLL into
Excel.

Test subjects have found receiving repeated messages from xlAutoOpen upon
every Excel startup to be annoying.

I've taken a look at the XLW source code and believe any modifications to
introduce this feature to be found within files
XlOpenClose.h
xlw.h

Discretion being the better part of valour, I have noticed that there is
working undocumented functionality for xlAutoRemove within the code.

Before I start meddling, could someone please advise me as to why xlAutoAdd
wasn't incorporated into XLW? If there are development notes available
other than the summary at
http://xlw.sourceforge.net/history.shtml
I would be glad to learn so that I can read those please.

Similarly, any links or advice regarding thorough testing for any
modifications to XLW code would be greatly appreciated.

I spent many unhappy hours unsuccessfully trying to get my XLL to work for
both 32-bit and 64-bit versions of Excel using the MS XLL SDK and advice
from Steve Dalton's excellent book before success using XLW. I really don't
want to start experimenting with stable library code if there's a good
reason I shouldn't even consider it in the first place!

Thanks for reading and best wishes,

And.

[Xlw-users] Sad news regarding Mark Joshi

[John A. <jo...@th...>]

I was very sorry to hear earlier in the week that Mark Joshi passed
away suddenly on the 8th October.

http://fbe.unimelb.edu.au/home/newsroom/obituary-for-professor-mark-jos
i

For those wishing to leave messages for his family there is a guest
book

http://www.legacy.com/obituaries/name/mark-joshi-obituary?pid=186899749
&view=guestbook

My thoughts are with his wife and 5 sons in this very sad time.

John

[Xlw-users] Feature Request: CellMatrix::Resize()

[<da...@gm...>]

Hi,

I'd like to ask for the possibility to resize the CellMatrix after
construction.
In the CellMatrix class:

// resize matrix
// - if size grows: preserves existing data and fills with default
constructed CellValue
// - if size shrinks: discards excess data
void Resize(size_t rows, size_t columns);

The implementation for class MJCellMatrix is trivial:

void xlw::impl::MJCellMatrix::Resize(size_t rows, size_t columns)
{
       Cells.resize(rows);
       for (size_t i=0; i < rows; i++)
        Cells[i].resize(columns);
}

I'll be glad to provide a patch if necessary.

My use case is resizing a matrix that is returned by an addin function, so
that it occupies all the caller range, to avoid getting all N/A's in part
of the caller range when it is larger than the returned CellMatrix.

I have patched my local copy of xlw, but I thought this might be useful for
other users.

Thanks in advance.

[Xlw-users] track version of XLL in the resource file in VS C++

[Liu, L. <Lu...@fi...>]

Hi,

I've been successfully built the XLL excel add-in and now I want to create a resource .rc file to track the version of my XLL. However, it is not working. For my other DLLs that I built in C++, I can see good values if I right click on the DLL and go to properties->details. can anyone help? Thanks!

Regards,
Lu

The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

[Xlw-users] VS 2017

[Matthias R. <mr...@gm...>]

My company wants to buy new licenses for VS 2017.
When will XLW be ready to support VS 2017?

Matt

Re: [Xlw-users] Strange behaviour - memory leak?

[Matthias R. <mr...@gm...>]

Hi John,

Replace is equivalent to the German "Ersetzen".
But I do not understand "Paste" - is this the "Paste" for the "Paste" in
"Paste special"?
Then this would be "Inhalte einfügen".

Matt




On Sat, Jul 15, 2017 at 7:01 PM, John Adcock <jo...@th...> wrote:

> Matt
>
> Ahh there is is an issue with the international versions that we check for
> the English strings when trying to tell if the dialog box is open
>
> In the code
>
>             // we know it is an excel window but we don't yet know if it
> is the
>             // function wizard, we need to avoid find and replace and
>             // the paste and collect windows (we don't just look for
> Function so that
>             // international versions at least get the function wizard
> working
>             if (!strstr(rgsz, "Replace") && !strstr(rgsz, "Paste")) {
>                 pEnum->bFuncWiz = TRUE;
>
>
> That means that if you relpace (or add) those strings with the equivialent
> German then it should work.
>
> Let me know what the right words are and I'll add them to the code.
>
> John
>
>
> On 30 June 2017 at 09:24, Matthias Ruess <mr...@gm...> wrote:
>
>> Hi John,
>> no I am using the German version of Excel 2013 - 32 bit
>> Matt
>>
>>
>> On Fri, Jun 30, 2017 at 12:00 AM, John Adcock <jo...@th...>
>> wrote:
>>
>>> Are you using the English version of Excel?
>>>
>>> John
>>>
>>> On Mon, 2017-06-26 at 10:34 +0200, Matthias Ruess wrote:
>>> > Hi John,
>>> >
>>> > I downloaded it more than a year ago but still seems to be the newest
>>> > version (xlw-5.0.2f0):
>>> > https://sourceforge.net/projects/xlw/files/xlw/xlw%205.0/xlw-5.0.2f0.
>>> > exe/download
>>> >
>>> > Matt
>>> >
>>> > On Sun, Jun 25, 2017 at 8:11 PM, John Adcock <jo...@th...>
>>> > wrote:
>>> > > > thanks for your help.
>>> > > > But why is
>>> > > > XlfExcel::Instance().IsCalledByFuncWiz()
>>> > > > equal to TRUE
>>> > > > when changing an Excel Formula via the Find and Replace dialog
>>> > > > box in Excel (Ctrl+H).
>>> > > >
>>> > > > Is there a way to distinguish between
>>> > > > IsCalledByFuncWiz()
>>> > > > and something like
>>> > > > IsCalledByFindAndReplace()
>>> > > >
>>> > > > Furthermore, I do not understand why
>>> > > > XlfExcel::Instance().IsCalledByFuncWiz()
>>> > > > is not set back to FALSE when reentering an XLW-formula with
>>> > > > ENTER.
>>> > > >
>>> > > >
>>> > >
>>> > > Which version of xlw are you using, I added a fix for this issue a
>>> > > while ago.
>>> > >
>>> > > John
>>> > >
>>> >
>>> >
>>>
>>
>>
>

[Xlw-users] dev6 branch: cpp files missing an include

[Tony M. <to...@ma...>]

Hello,

I am compiling the dev6 branch of the xlw library with Visual Studio 2015,
and noticed that the files XlfCmdDesc.cpp and XlfFuncDesc.cpp are missing
#include <xlw/XlfServices.h>. When I added this include, the files compiled
without error.

Is this the correct fix to apply?

Regards

Tony

Re: [Xlw-users] XlfWindows defines WINVER, causes problems

[John A. <jo...@th...>]

Tony

Thanks a lot for that, I've made the change in svn.

John

On 14 July 2017 at 08:54, Tony Marshall <to...@ma...> wrote:

> I am compiling my application using the dev6 branch of xlw and the Visual
> Studio 2015 compiler.
>
> I have a problem with the XlfWindows.h defining WINVER=0x400 when compiled
> by the Microsoft compiler.
>
> Let me state my proposed solution first, then I'll explain the actual
> problem.
>
> XlfWindows.h should not set the value of WINVER if it is already defined
> by the Visual Studio project that is compiling the application code that
> uses XLW. Doing so can cause compiler errors due to Windows API functions
> having different signatures in different versions of Windows.
>
> So I propose the following change to XlfWindows.h:
> #ifndef _MSC_VER
> // shouldn't really be required
> // but the mingw headers set OpenThread as 0x0500
> // minimum
> #ifndef WINVER
> #define WINVER 0x0500
> #endif
> #else
> // THIS IS THE CHANGE: ONLY DEFINE WINVER IF NOT ALREADY SET
> #ifndef WINVER
> // with msvc allow standard 2000 minimum
> #define WINVER 0x0400
> #endif
> #endif
>
> My problem arose because when XlfWindows.h sets WINVER=0x400, BOOST v1.64
> code fails to compile in win_thread.ipp, line 54. It
> calls ::QueueUserAPC(apc_function, thread_, 0), which is a Windows API
> function, and the VS2015 compiler reports the following error:
>
> error C2664: 'DWORD QueueUserAPC(PAPCFUNC,HANDLE,ULONG_PTR)': cannot
> convert argument 1 from 'void (__cdecl *)(ULONG)' to 'PAPCFUNC'
>
> The PAPCFUNC type is different between WINVER=0x400 AND 0x500: in 0x400 it
> is void (__cdecl*)(ULONG) and in 0x500 it is void (__cdecl*)(ULONG_PTR).
>
> I haven't tracked down exactly how the conflict occurs between the use of
> the boost and xlw libraries, as it's a laborious process. But that doesn't
> really matter; there's a conflict and the solution is the above proposal.
> Other libraries implement this solution (including boost), probably for
> this reason.
>
> Regards
>
> Tony
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Xlw-users mailing list
> Xlw...@li...
> https://lists.sourceforge.net/lists/listinfo/xlw-users
>
>

[Xlw-users] XlfWindows defines WINVER, causes problems

[Tony M. <to...@ma...>]

I am compiling my application using the dev6 branch of xlw and the Visual
Studio 2015 compiler.

I have a problem with the XlfWindows.h defining WINVER=0x400 when compiled
by the Microsoft compiler.

Let me state my proposed solution first, then I'll explain the actual
problem.

XlfWindows.h should not set the value of WINVER if it is already defined by
the Visual Studio project that is compiling the application code that uses
XLW. Doing so can cause compiler errors due to Windows API functions having
different signatures in different versions of Windows.

So I propose the following change to XlfWindows.h:
#ifndef _MSC_VER
// shouldn't really be required
// but the mingw headers set OpenThread as 0x0500
// minimum
#ifndef WINVER
#define WINVER 0x0500
#endif
#else
// THIS IS THE CHANGE: ONLY DEFINE WINVER IF NOT ALREADY SET
#ifndef WINVER
// with msvc allow standard 2000 minimum
#define WINVER 0x0400
#endif
#endif

My problem arose because when XlfWindows.h sets WINVER=0x400, BOOST v1.64
code fails to compile in win_thread.ipp, line 54. It
calls ::QueueUserAPC(apc_function, thread_, 0), which is a Windows API
function, and the VS2015 compiler reports the following error:

error C2664: 'DWORD QueueUserAPC(PAPCFUNC,HANDLE,ULONG_PTR)': cannot
convert argument 1 from 'void (__cdecl *)(ULONG)' to 'PAPCFUNC'

The PAPCFUNC type is different between WINVER=0x400 AND 0x500: in 0x400 it
is void (__cdecl*)(ULONG) and in 0x500 it is void (__cdecl*)(ULONG_PTR).

I haven't tracked down exactly how the conflict occurs between the use of
the boost and xlw libraries, as it's a laborious process. But that doesn't
really matter; there's a conflict and the solution is the above proposal.
Other libraries implement this solution (including boost), probably for
this reason.

Regards

Tony

Re: [Xlw-users] Strange behaviour - memory leak?

[John A. <jo...@th...>]

Are you using the English version of Excel?

John

On Mon, 2017-06-26 at 10:34 +0200, Matthias Ruess wrote:
> Hi John,
> 
> I downloaded it more than a year ago but still seems to be the newest
> version (xlw-5.0.2f0):
> https://sourceforge.net/projects/xlw/files/xlw/xlw%205.0/xlw-5.0.2f0.
> exe/download
> 
> Matt
> 
> On Sun, Jun 25, 2017 at 8:11 PM, John Adcock <jo...@th...>
> wrote:
> > > thanks for your help.
> > > But why is
> > > XlfExcel::Instance().IsCalledByFuncWiz()
> > > equal to TRUE
> > > when changing an Excel Formula via the Find and Replace dialog
> > > box in Excel (Ctrl+H).
> > > 
> > > Is there a way to distinguish between 
> > > IsCalledByFuncWiz()
> > > and something like
> > > IsCalledByFindAndReplace()
> > > 
> > > Furthermore, I do not understand why 
> > > XlfExcel::Instance().IsCalledByFuncWiz()
> > > is not set back to FALSE when reentering an XLW-formula with
> > > ENTER.
> > > 
> > > 
> > 
> > Which version of xlw are you using, I added a fix for this issue a
> > while ago.
> > 
> > John 
> > 
> 
> 

Re: [Xlw-users] Strange behaviour - memory leak?

[Matthias R. <mr...@gm...>]

Hi John,

I downloaded it more than a year ago but still seems to be the newest
version (xlw-5.0.2f0):
https://sourceforge.net/projects/xlw/files/xlw/xlw%205.0/xlw-5.0.2f0.exe/download

Matt

On Sun, Jun 25, 2017 at 8:11 PM, John Adcock <jo...@th...> wrote:

> thanks for your help.
>> But why is
>> XlfExcel::Instance().IsCalledByFuncWiz()
>> equal to TRUE
>> when changing an Excel Formula via the Find and Replace dialog box in
>> Excel (Ctrl+H).
>>
>> Is there a way to distinguish between
>> IsCalledByFuncWiz()
>> and something like
>> IsCalledByFindAndReplace()
>>
>> Furthermore, I do not understand why
>> XlfExcel::Instance().IsCalledByFuncWiz()
>> is not set back to FALSE when reentering an XLW-formula with ENTER.
>>
>>
> Which version of xlw are you using, I added a fix for this issue a while
> ago.
>
> John
>

Re: [Xlw-users] Strange behaviour - memory leak?

[John A. <jo...@th...>]

>
> thanks for your help.
> But why is
> XlfExcel::Instance().IsCalledByFuncWiz()
> equal to TRUE
> when changing an Excel Formula via the Find and Replace dialog box in
> Excel (Ctrl+H).
>
> Is there a way to distinguish between
> IsCalledByFuncWiz()
> and something like
> IsCalledByFindAndReplace()
>
> Furthermore, I do not understand why
> XlfExcel::Instance().IsCalledByFuncWiz()
> is not set back to FALSE when reentering an XLW-formula with ENTER.
>
>
Which version of xlw are you using, I added a fix for this issue a while
ago.

John

Re: [Xlw-users] Strange behaviour - memory leak?

[Matthias R. <mr...@gm...>]

Hi Mark,

after deleting the corresponding rows (256-258) in Outputter.cpp and
recompiling the InterfaceGenerator everything works as expected.
But as you pointed out this is only a good idea for fast evaluating
functions.
It seems to be an Excel-Bug that the Find and Replace dialog box triggers
an "isCalledByFuncWiz()"-calalculation.
Thank you for your help.

Cheers, Matt

On Wed, May 24, 2017 at 11:27 PM, Mark joshi <mar...@gm...> wrote:

> regarding your first few questions -- no idea.
>
> Regarding the last one, no. But it would be easy to change the
> interface generator to do this.
>
> best
> Mark
>
>
> On 24 May 2017 at 21:27, Matthias Ruess <mr...@gm...> wrote:
> > Hi Mark,
> >
> > thanks for your help.
> > But why is
> > XlfExcel::Instance().IsCalledByFuncWiz()
> > equal to TRUE
> > when changing an Excel Formula via the Find and Replace dialog box in
> Excel
> > (Ctrl+H).
> >
> > Is there a way to distinguish between
> > IsCalledByFuncWiz()
> > and something like
> > IsCalledByFindAndReplace()
> >
> > Furthermore, I do not understand why
> > XlfExcel::Instance().IsCalledByFuncWiz()
> > is not set back to FALSE when reentering an XLW-formula with ENTER.
> >
> > Is there any flag in XLW that removes the following two lines
> automatically
> > if (XlfExcel::Instance().IsCalledByFuncWiz())
> >     return XlfOper(true);
> > ?
> >
> > Matt
> >
> > On Tue, May 23, 2017 at 11:06 PM, Mark joshi <mar...@gm...>
> wrote:
> >>
> >> if (XlfExcel::Instance().IsCalledByFuncWiz())
> >>     return XlfOper(true);
> >>
> >> is there because often xlw defined functions are slow to evaluate. For
> >> example, suppose every time you changed an entry in the function
> >> wizard a 100,00 path Monte Carlo simulation ran then the wizard would
> >> become unusable.
> >>
> >> So if all your functions are fast to evaluate, it's safe to remove.
> >> But if some aren't, don't do it.
> >>
> >> regards
> >> Mark
> >>
> >>
> >> On 24 May 2017 at 01:49, Matthias Ruess <mr...@gm...> wrote:
> >> > I think I have found the error - somehow when replacing the equal sign
> >> > XlfExcel::Instance().IsCalledByFuncWiz()
> >> > is set to TRUE
> >> >
> >> > and thus
> >> > if (XlfExcel::Instance().IsCalledByFuncWiz())
> >> >     return XlfOper(true);
> >> >
> >> > Is it a good idea to remove
> >> > if (XlfExcel::Instance().IsCalledByFuncWiz())
> >> >     return XlfOper(true);
> >> > ?
> >> >
> >> > Matt
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > ------------------------------------------------------------
> ------------------
> >> > Check out the vibrant tech community on one of the world's most
> >> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> > _______________________________________________
> >> > Xlw-users mailing list
> >> > Xlw...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/xlw-users
> >> >
> >>
> >>
> >>
> >> --
> >>
> >> Prof Mark Joshi
> >> Director, Centre for Actuarial Studies
> >> University of Melbourne
> >> My website is www.markjoshi.com
> >
> >
>
>
>
> --
>
> Prof Mark Joshi
> Director, Centre for Actuarial Studies
> University of Melbourne
> My website is www.markjoshi.com
>