Compiler errors

Doomsayer · Jul 9, 2004, 11:06 PM

I'm trying to compile the fx_demo program from the SDK, and I have problems. There's a conflict between kDefs.h and the system's atlconv.h - same functions AtlA2WHelper, AtlW2AHelper, AtlA2WHelper, AtlW2AHelper and macros A2W, W2A are defined. Their bodies are somewhat different in the two files. Trying to comment them out in kDefs.h leads to a perfect compile, but later to an assertion fail in winocc.cpp line 290 as soon as I press "tweak" on the plugin in the DSP. Commenting them out in atlconv.h leads to lots of "undeclared identifier" compiler errors. Using Visual C++ 7.0. So what am I doing wrong?

Tiger M · Jul 10, 2004, 06:54 AM

That is strange. I've been using VC 6.0 and haven't had such problems at all. Did you try to compile it as it was, without altering the code or the project settings in any way?

Doomsayer · Jul 10, 2004, 09:40 AM

The project/code wasn't altered in any way. atlconv.h gets included with some mfc header files, as far as I understand. Any ideas on how to resolve this problem?

Tiger M · Jul 10, 2004, 10:25 AM

fx_demo should be all right, being already compiled in the SDK distribution and working fine.
This must be a kX SDK <-> VC 7.0 relation issue, because there are no such problems in 6.0.

The difference between kDefs.h and atlconv.h is:

ASSERT(something... != NULL); //kDefs

ATLASSERT(something... != NULL); //atlconv.h

Surely Eugene would know what this is about. I'll send him a mail.

You can switch back to VC 6.0, but I don't know if this would be very comfortable for you for such a small problem.

Doomsayer · Jul 10, 2004, 10:37 AM

The contents of my atlconv.h (hope I don't get massacred for posting its contents

) :
inline LPWSTR WINAPI AtlA2WHelper(LPWSTR lpw, LPCSTR lpa, int nChars, UINT acp) throw()
{
ATLASSERT(lpa != NULL);
ATLASSERT(lpw != NULL);
if (lpw == NULL)
return NULL;
// verify that no illegal character present
// since lpw was allocated based on the size of lpa
// don't worry about the number of chars
lpw[0] = '\0';
MultiByteToWideChar(acp, 0, lpa, -1, lpw, nChars);
return lpw;
}

inline LPSTR WINAPI AtlW2AHelper(LPSTR lpa, LPCWSTR lpw, int nChars, UINT acp) throw()
{
ATLASSERT(lpw != NULL);
ATLASSERT(lpa != NULL);
if (lpa == NULL)
return NULL;
// verify that no illegal character present
// since lpa was allocated based on the size of lpw
// don't worry about the number of chars
lpa[0] = '\0';
WideCharToMultiByte(acp, 0, lpw, -1, lpa, nChars, NULL, NULL);
return lpa;
}
inline LPWSTR WINAPI AtlA2WHelper(LPWSTR lpw, LPCSTR lpa, int nChars) throw()
{
return AtlA2WHelper(lpw, lpa, nChars, CP_ACP);
}

inline LPSTR WINAPI AtlW2AHelper(LPSTR lpa, LPCWSTR lpw, int nChars) throw()
{
return AtlW2AHelper(lpa, lpw, nChars, CP_ACP);
}
/*... Some more defines here ... */
#define A2W(lpa) (\
((_lpa = lpa) == NULL) ? NULL : (\
_convert = (lstrlenA(_lpa)+1),\
ATLA2WHELPER((LPWSTR) alloca(_convert*2), _lpa, _convert, _acp)))

#define W2A(lpw) (\
((_lpw = lpw) == NULL) ? NULL : (\
_convert = (lstrlenW(_lpw)+1)*2,\
ATLW2AHELPER((LPSTR) alloca(_convert), _lpw, _convert, _acp)))

Please check if yours are the same (I mean for VC++ 6.0). Also, how is this not a conflict on your system? Is atlconv.h not #included in your MFC headers?

Tiger M · Jul 10, 2004, 12:08 PM

There is a difference. Here it is:

throw() //this is not present in VC 6.0 version of the header

I'll tell you what we'll do, but we should switch to PMs for that...

Doomsayer · Jul 10, 2004, 08:59 PM

Well, another interesting thing I noticed. These functions/macros aren't used anywhere in the demo. So this means that I can safely comment them out. But then the abovementioned Assertion Fail seems to prove that there's deeper incompatibility between SDK 3537 and VC 7.0 include files...
The Assertion Fail happens here :
int CWnd::GetDlgCtrlID() const
{
ASSERT(::IsWindow(m_hWnd) || (m_pCtrlSite != NULL)); // Line 290

if (m_pCtrlSite == NULL)
return ::GetDlgCtrlID(m_hWnd);
else
return m_pCtrlSite->GetDlgCtrlID();
}
Perhaps this thread should be moved to the bug reports section?

Doomsayer · Jul 10, 2004, 09:07 PM

Btw, the Assertion Fail is caused by kxmixer.exe, so I'm not even sure if it's MY winocc.cpp where the error occurs. Probably it isn't.
Anyway, I seem to have narrowed the problem to one call inside iDemoPlugin::create_cp, namely tmp->create(). I'm afraid only the developer can investigate further...

Tiger M · Jul 10, 2004, 10:42 PM

Quote:

Btw, the Assertion Fail is caused by kxmixer.exe

This is always the case when you get a plugin compiled without errors in VC, but there is still something wrong or missing in the code. I had this type of error many times

.

I think this is the right place for this thread, but it actually doesn't matter, because nobody of the regular users would understand it anyway

.

btw, the 'Effects and the DSP' forum was intended by Eugene mostly for programmers and code sharing. It didn't turn out to be so, which is sad...

Here is one very dramatic episode of kX history, take a look, its a real drama:

http://www.hardwareheaven.com/showthre...ght=distortion

Tiger M · Jul 11, 2004, 05:57 PM

Check out your PM box again...

Lex Nahumury · Jul 12, 2004, 05:09 AM

>>I think this is the right place for this thread,
Yes it is,.. So by all means continue..!!

>>but it actually doesn't matter, because nobody of the regular users would understand it anyway.

>>Here is one very dramatic episode of kX history, take a look, its a real drama:
I got over it ...

/LeMury

Tiger M · Jul 12, 2004, 05:57 AM

Yes, I think that it will be nice if I put the conclusion here, so anyone interested in plugins programing will be informed:

The best (and maybe the only working) compiler for kX Project related programming is MS Visual C++ 6.0.
VC++ 7.0 or .NET doesn't seem to work due to MFC changes.

Tiger M · Jul 12, 2004, 06:13 AM

And here is the final conclusion and solution directly from Eugene:

"yes, VC7 uses different headers & binaries and is not 100% compatible with
kX SDK.
you may, however, use it provided you point to the original VC6 headers in
your project"

Its clear what should be done...

**dj_stick** · Jul 12, 2004, 06:17 AM

bloody microsoft and their non-standard following apps

Soeren_B · Jul 12, 2004, 07:26 AM

A little browsing in this forum should tell you this, since it has been discussed before.
MS Visual Studio 7 (.Net) will not work for creating kX-plugins.

Cheers
Soeren

Tiger M · Jul 12, 2004, 08:40 AM

Quote:

MS Visual Studio 7 (.Net) will not work for creating kX-plugins.

Did you read the previous posts?
VC 7 itself will work, provided that you have VC 6 MFC headers.

By the way, I have read the thread you're speaking of, yes.

Doomsayer · Jul 12, 2004, 11:37 AM

Well, that's sad. It's just another problem in the way of those who wish to participate actively in the kX community. And VS 7 is gaining in popularity, btw... Anyway, when I get past this problem, I'll post a how-to

Soeren_B · Jul 13, 2004, 08:24 AM

Quote:

Originally posted by Tiger M
Did you read the previous posts?

Cool the jets

Do you know if it is possible to get the VC 6 MFC headers somewhere (free, as in beer)?
I am still using VC 6, but it would be nice to be able to show people the old headers. Still, if they want to make kX plugs badly enough they should be able to locate them by themselves

/Soeren

Tiger M · Jul 13, 2004, 10:38 AM

Quote:

if they want to make kX plugs badly enough they should be able to locate them by themselves

aha, right, but the truth is that I really like to encourage dsp development among kX users.
its a great shame that kX project is such a superb environment and there are only 7-8 people in the whole world to venture in programming it

Have fun.

**dj_stick** · Jul 13, 2004, 02:00 PM

Quote:

Originally posted by Tiger M
aha, right, but the truth is that I really like to encourage dsp development among kX users.
its a great shame that kX project is such a superb environment and there are only 7-8 people in the whole world to venture in programming it

Have fun.

when i get the time i'm gonna take a good look at your guide and see what i can come up with - but i have never done any programming before so it may take a while

Soeren_B · Jul 13, 2004, 02:26 PM

Quote:

Originally posted by Tiger M
aha, right, but the truth is that I really like to encourage dsp development among kX users.
its a great shame that kX project is such a superb environment and there are only 7-8 people in the whole world to venture in programming it
Have fun.

So would I, and that is why I suggested that a more detailed desciption of a full plugin (with C++ GUI code) was added.
Still, I think it will be more feasible to make an "Advanced DSP programming guide" including all the pitfalls and strange issues that may occur in the process (for instance, these compiler issues).

/Soeren

P.S. I didn't actually mean that people should go hunting for the VC 6 headers on their own. We should rather provide these headers or at least the information reqiured to build plugins in some official manner.

**dj_stick** · Jul 13, 2004, 02:28 PM

if you can fins such headers i shall post the on the knowledgebase for use by DSP programmers

Tiger M · Jul 13, 2004, 03:48 PM

Quote:

So would I, and that is why I suggested that a more detailed desciption of a full plugin (with C++ GUI code) was added.
Still, I think it will be more feasible to make an "Advanced DSP programming guide" including all the pitfalls and strange issues that may occur in the process (for instance, these compiler issues).

That's right, we all know very well that kX project lacks detailed info on almost all programming aspects. I rememer when I tried to put a skin on one plugin, man, I nibbled my nails for several days, until I figured it out with help from LeMury. Who would guess that you need such complicated (actually doubled) code to make a simple bitmapped slider? And what was described in the scarce skin example turned out to be wrong (maybe outdated is the correct word)!

Such a guide should be written.

Quote:

if you can fins such headers i shall post the on the knowledgebase for use by DSP programmers

don't do that, or we'll be seeing you in court

Doomsayer · Jul 15, 2004, 02:08 PM

Well, the solution is just as was expected. In order to be able to correctly build the SDK3537 demo I needed the VC98\MFC\INCLUDE and VC98\MFC\LIB directories from Visual C++ 6.0. These had to be added to Tools->Options->Projects->VC++ Directories BEFORE the atlmfc folder of VC 7.0, both for lib and include files. Apparently nothing else is needed, at least not for the demo. I'll keep updating this thread if I find any other problems/solutions. Hopefully I can start coding now

Tiger M · Jul 15, 2004, 05:02 PM

Good job, Doomsayer. I'm glad you solve it.

I'm shure you won't have further problems, provided that you've compiled the demo succesfully.

Have fun coding...

HughJorgan · Dec 6, 2005, 06:09 PM

Actually, all you need to do is put the following line of code before your string conversion calls:

USES_CONVERSION;

This macro defines all the necessary variables. That's it! Worked for me.

-Hugh Jorgan

Jul 9, 2004, 11:06 PM	#1
Doomsayer DriverHeaven Lover Join Date: Feb 2004 Location: Latvia Posts: 154 Rep Power: 0	Compiler errors I'm trying to compile the fx_demo program from the SDK, and I have problems. There's a conflict between kDefs.h and the system's atlconv.h - same functions AtlA2WHelper, AtlW2AHelper, AtlA2WHelper, AtlW2AHelper and macros A2W, W2A are defined. Their bodies are somewhat different in the two files. Trying to comment them out in kDefs.h leads to a perfect compile, but later to an assertion fail in winocc.cpp line 290 as soon as I press "tweak" on the plugin in the DSP. Commenting them out in atlconv.h leads to lots of "undeclared identifier" compiler errors. Using Visual C++ 7.0. So what am I doing wrong?

Jul 10, 2004, 06:54 AM	#2
Tiger M kX user Join Date: Apr 2004 Posts: 851 Rep Power: 0	That is strange. I've been using VC 6.0 and haven't had such problems at all. Did you try to compile it as it was, without altering the code or the project settings in any way? __________________ Miss you, Steve...

Jul 10, 2004, 10:25 AM	#4
Tiger M kX user Join Date: Apr 2004 Posts: 851 Rep Power: 0	fx_demo should be all right, being already compiled in the SDK distribution and working fine. This must be a kX SDK <-> VC 7.0 relation issue, because there are no such problems in 6.0. The difference between kDefs.h and atlconv.h is: ASSERT(something... != NULL); //kDefs ATLASSERT(something... != NULL); //atlconv.h Surely Eugene would know what this is about. I'll send him a mail. You can switch back to VC 6.0, but I don't know if this would be very comfortable for you for such a small problem. __________________ Miss you, Steve... Last edited by Tiger M; Jul 12, 2004 at 06:54 AM.

Jul 10, 2004, 10:37 AM	Thread Starter #5
Doomsayer DriverHeaven Lover Join Date: Feb 2004 Location: Latvia Posts: 154 Rep Power: 0	The contents of my atlconv.h (hope I don't get massacred for posting its contents ) : inline LPWSTR WINAPI AtlA2WHelper(LPWSTR lpw, LPCSTR lpa, int nChars, UINT acp) throw() { ATLASSERT(lpa != NULL); ATLASSERT(lpw != NULL); if (lpw == NULL) return NULL; // verify that no illegal character present // since lpw was allocated based on the size of lpa // don't worry about the number of chars lpw[0] = '\0'; MultiByteToWideChar(acp, 0, lpa, -1, lpw, nChars); return lpw; } inline LPSTR WINAPI AtlW2AHelper(LPSTR lpa, LPCWSTR lpw, int nChars, UINT acp) throw() { ATLASSERT(lpw != NULL); ATLASSERT(lpa != NULL); if (lpa == NULL) return NULL; // verify that no illegal character present // since lpa was allocated based on the size of lpw // don't worry about the number of chars lpa[0] = '\0'; WideCharToMultiByte(acp, 0, lpw, -1, lpa, nChars, NULL, NULL); return lpa; } inline LPWSTR WINAPI AtlA2WHelper(LPWSTR lpw, LPCSTR lpa, int nChars) throw() { return AtlA2WHelper(lpw, lpa, nChars, CP_ACP); } inline LPSTR WINAPI AtlW2AHelper(LPSTR lpa, LPCWSTR lpw, int nChars) throw() { return AtlW2AHelper(lpa, lpw, nChars, CP_ACP); } /... Some more defines here ... / #define A2W(lpa) (\ ((_lpa = lpa) == NULL) ? NULL : (\ _convert = (lstrlenA(_lpa)+1),\ ATLA2WHELPER((LPWSTR) alloca(_convert2), _lpa, _convert, _acp))) #define W2A(lpw) (\ ((_lpw = lpw) == NULL) ? NULL : (\ _convert = (lstrlenW(_lpw)+1)2,\ ATLW2AHELPER((LPSTR) alloca(_convert), _lpw, _convert, _acp))) Please check if yours are the same (I mean for VC++ 6.0). Also, how is this not a conflict on your system? Is atlconv.h not #included in your MFC headers? Last edited by Doomsayer; Jul 10, 2004 at 10:42 AM.

Jul 10, 2004, 12:08 PM	#6
Tiger M kX user Join Date: Apr 2004 Posts: 851 Rep Power: 0	There is a difference. Here it is: throw() //this is not present in VC 6.0 version of the header I'll tell you what we'll do, but we should switch to PMs for that... __________________ Miss you, Steve...

Jul 10, 2004, 09:40 AM	Thread Starter #3
Doomsayer DriverHeaven Lover Join Date: Feb 2004 Location: Latvia Posts: 154 Rep Power: 0	The project/code wasn't altered in any way. atlconv.h gets included with some mfc header files, as far as I understand. Any ideas on how to resolve this problem?

Jul 10, 2004, 08:59 PM	Thread Starter #7
Doomsayer DriverHeaven Lover Join Date: Feb 2004 Location: Latvia Posts: 154 Rep Power: 0	Well, another interesting thing I noticed. These functions/macros aren't used anywhere in the demo. So this means that I can safely comment them out. But then the abovementioned Assertion Fail seems to prove that there's deeper incompatibility between SDK 3537 and VC 7.0 include files... The Assertion Fail happens here : int CWnd::GetDlgCtrlID() const { ASSERT(::IsWindow(m_hWnd) \|\| (m_pCtrlSite != NULL)); // Line 290 if (m_pCtrlSite == NULL) return ::GetDlgCtrlID(m_hWnd); else return m_pCtrlSite->GetDlgCtrlID(); } Perhaps this thread should be moved to the bug reports section?

Jul 10, 2004, 09:07 PM	Thread Starter #8
Doomsayer DriverHeaven Lover Join Date: Feb 2004 Location: Latvia Posts: 154 Rep Power: 0	Btw, the Assertion Fail is caused by kxmixer.exe, so I'm not even sure if it's MY winocc.cpp where the error occurs. Probably it isn't. Anyway, I seem to have narrowed the problem to one call inside iDemoPlugin::create_cp, namely tmp->create(). I'm afraid only the developer can investigate further... Last edited by Doomsayer; Jul 10, 2004 at 09:19 PM.

Jul 11, 2004, 05:57 PM	#10
Tiger M kX user Join Date: Apr 2004 Posts: 851 Rep Power: 0	Check out your PM box again... __________________ Miss you, Steve...

Jul 12, 2004, 05:09 AM	#11
Lex Nahumury DH Senior Member Join Date: Jan 2003 Location: The Netherlands Posts: 1,932 Rep Power: 64	>>I think this is the right place for this thread, Yes it is,.. So by all means continue..!! >>but it actually doesn't matter, because nobody of the regular users would understand it anyway. >>Here is one very dramatic episode of kX history, take a look, its a real drama: I got over it ... /LeMury

Jul 12, 2004, 05:57 AM	#12
Tiger M kX user Join Date: Apr 2004 Posts: 851 Rep Power: 0	Yes, I think that it will be nice if I put the conclusion here, so anyone interested in plugins programing will be informed: The best (and maybe the only working) compiler for kX Project related programming is MS Visual C++ 6.0. VC++ 7.0 or .NET doesn't seem to work due to MFC changes. __________________ Miss you, Steve...

Jul 12, 2004, 06:13 AM	#13
Tiger M kX user Join Date: Apr 2004 Posts: 851 Rep Power: 0	And here is the final conclusion and solution directly from Eugene: "yes, VC7 uses different headers & binaries and is not 100% compatible with kX SDK. you may, however, use it provided you point to the original VC6 headers in your project" Its clear what should be done... __________________ Miss you, Steve...

Jul 12, 2004, 07:26 AM	#15
Soeren_B kX Project DSP Engineer Join Date: Dec 2002 Location: Denmark Posts: 94 Rep Power: 0	A little browsing in this forum should tell you this, since it has been discussed before. MS Visual Studio 7 (.Net) will not work for creating kX-plugins. Cheers Soeren

Jul 12, 2004, 11:37 AM	Thread Starter #17
Doomsayer DriverHeaven Lover Join Date: Feb 2004 Location: Latvia Posts: 154 Rep Power: 0	Well, that's sad. It's just another problem in the way of those who wish to participate actively in the kX community. And VS 7 is gaining in popularity, btw... Anyway, when I get past this problem, I'll post a how-to

Jul 15, 2004, 02:08 PM	Thread Starter #24
Doomsayer DriverHeaven Lover Join Date: Feb 2004 Location: Latvia Posts: 154 Rep Power: 0	Well, the solution is just as was expected. In order to be able to correctly build the SDK3537 demo I needed the VC98\MFC\INCLUDE and VC98\MFC\LIB directories from Visual C++ 6.0. These had to be added to Tools->Options->Projects->VC++ Directories BEFORE the atlmfc folder of VC 7.0, both for lib and include files. Apparently nothing else is needed, at least not for the demo. I'll keep updating this thread if I find any other problems/solutions. Hopefully I can start coding now

Jul 15, 2004, 05:02 PM	#25
Tiger M kX user Join Date: Apr 2004 Posts: 851 Rep Power: 0	Good job, Doomsayer. I'm glad you solve it. I'm shure you won't have further problems, provided that you've compiled the demo succesfully. Have fun coding... __________________ Miss you, Steve...

Dec 6, 2005, 06:09 PM	#26
HughJorgan DriverHeaven Newbie Join Date: Dec 2005 Posts: 1 Rep Power: 0	A quick fix for this problem... Actually, all you need to do is put the following line of code before your string conversion calls: USES_CONVERSION; This macro defines all the necessary variables. That's it! Worked for me. -Hugh Jorgan