User (Legacy) Posted April 12, 2002 Report Share Posted April 12, 2002 Hi, I have observed bad behaviour of the Chart FX Client Server 5.0 method for Title property. The applicaction uses DLL from C++ code compiled by MS Visual C++ 6.0. The #import directive (Cfx4030.dll ver 5.0.4.0) is used for generating Cfx4032.tli. One of the generated wrapping methods looks like this: LPSTR IChartFX::GetTitle ( enum CfxTitle index ) { LPSTR _result; HRESULT _hr = get_Title(index, &_result); if (FAILED(_hr)) _com_issue_errorex(_hr, this, __uuidof(this)); return _result; } The problem is that no buffer is allocated for the result string, and the _result pointer is not initialized. The get_Title() returns hr == 0, but also the exception is raiset (I did not pay attention, but apparently the code tried something like to access unalocated memory via uninitialized pointer). This means, that it is not possible to call for example: m_spChartFX->GetTitle(CHART_TOPTIT); When I tried what is described in Q1381049 "Getting string properties using DLL", it worked fine. BTW, there is a minor bug in the snippet. It should look like: char s[256]; char * ps = s; m_spChartFX->get_Title(CHART_TOPTIT, &ps); Could you confirm that it is a bug or not? Thanks, Petr P.S. Is there a better place where to send bug reports? -- Petr Prikryl (prikrylp at skil dot cz) Link to comment Share on other sites More sharing options...
Software FX Posted April 15, 2002 Report Share Posted April 15, 2002 This is by-design in the DLL, strings are to be allocated by you to improve performance (so that you can decide where to allocate them, stack, global memory, etc.). You need to call directly to the raw functions using a previously allocated buffer. For example: char buffer[256]; char *s = buffer; pChart->get_Title(CHART_TOPTIT, &s); -- FP Software FX, Inc. Link to comment Share on other sites More sharing options...
User (Legacy) Posted April 16, 2002 Author Report Share Posted April 16, 2002 Hi, Thanks for your quick response. Just to make the things clear... FP wrote... > This is by-design in the DLL, strings are to be allocated by you to improve > performance (so that you can decide where to allocate them, stack, global > memory, etc.). > > You need to call directly to the raw functions using a previously allocated > buffer. For example: > > char buffer[256]; > char *s = buffer; > pChart->get_Title(CHART_TOPTIT, &s); I understand the solution and also the reason for allocating buffer this way. What I wanted to point out was that the method... LPSTR IChartFX::GetTitle ( enum CfxTitle index ) { LPSTR _result; HRESULT _hr = get_Title(index, &_result); if (FAILED(_hr)) _com_issue_errorex(_hr, this, __uuidof(this)); return _result; } which is generated automatically from Cfx4032.dll (into Cfx4032.tli) cannot be used, because it crashes the application. Or the interface of the method should be changed so, that it could accept the pointer to "manually" allocated buffer, or it should be removed from the interface. Does it make sense? Thanks, Petr P.S. I am not very good in COM (yet) to guess all the consequences, (whether it is possible or not) but you are, aren't you? ;-) Link to comment Share on other sites More sharing options...
Software FX Posted April 16, 2002 Report Share Posted April 16, 2002 The problem is we can not control it, if we remove the method then you will have no access to the raw function either. We can not tell VC++ to NOT generate a "wrapper" method for these members only. You can always use #import with "raw_interfaces_only" to prevent wrappers from being generated but this will apply to ALL methods which will make it more tedious to write the code that interacts with the chart. -- FP Software FX, Inc. Link to comment Share on other sites More sharing options...
User (Legacy) Posted April 17, 2002 Author Report Share Posted April 17, 2002 Hi, FP wrote... > > The problem is we can not control it, if we remove the method then you will > have no access to the raw function either. We can not tell VC++ to NOT > generate a "wrapper" method for these members only. [...] Thanks a lot. This explanation satisfies me. Petr -- Petr Prikryl (prikrylp at skil dot cz) Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.