|
Member 12888494 wrote: "Error C2664 'BOOL CFont::CreateFontW(int,int,int,int,int,BYTE,BYTE,BYTE,BYTE,BYTE,BYTE,BYTE,BYTE,LPCTSTR)':
Replace the source for that with:
CFont::CreateFontW(int,int,int,int,int,SPAM,SPAM,SPAM,SPAM,SPAM,SPAM,SPAM,SPAM,LPCTSTR)
|
|
|
|
|
Please to place mental litter generated while reading off-topic posts in appropriate waste container.
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
Change career, you havent the first clue about software and compilers have you?
|
|
|
|
|
He posted in the wrong forum for sure but that's rude and in violation of rule #1 and #6 of this very forum. He obviously has an issue. To post this 10 hours after the initial post and 9 hours after he re-posted in the appropriate section after being told to is uncouth.
|
|
|
|
|
Oh come on, he hasn't even the most basic understanding of data types and casting.
And he asks for help debugging? It doesn't even compile!
modified 11-Dec-16 4:02am.
|
|
|
|
|
I had a C++/CLI project I had to migrate from VS2013 to VS2015 that wouldn't compile in VS2015. I had to manually edit the .csproj file because of nuances between the two versions. I'm not saying it's not his fault but to assume that incurs the assumption you've never run into the same situation.
|
|
|
|
|
I am sure that happens, automatic conversion is bound to screw up sometimes but not being able to distinguish a const from non const data type is somewhat of an elementary failing wouldn't you say?
|
|
|
|
|
I think the issue has more to do with the character encoding used. He's attempting to assign an 8-bit encoding to a 16-bit value (char to wchar_t ). Any non-character-encoding expert has probably run into the same problem before - I know I have. The base Windows types don't have very descriptive names so often I have to look up what they mean. Personally, I've never dealt with an LPCTSTR before only LPCSTR and LPTSTR .
|
|
|
|
|
Its not really a problem though is it, a new version of VS has headers with string definitions tightened up in functions. Just cast them and all will be well.
|
|
|
|
|
It's a problem if you don't even understand the basic premise of why that encoding is different. I've said it in the past - programming is an infinitely complex topic in which no one, and I mean NO ONE, has a full grasp. Lifetimes of work can be encapsulated in a single topic.
Munchies_Matt wrote: Just cast them and all will be well.
That's an easy statement to say when you're familiar with the topic being discussed. That's an entirely different monster when you have no character encoding experience or experience with Windows types. You even mention the fact that wchar_t is a header definition for an unsigned short in your response. How many average coders do you really expect to have read the header file for wchar.h or its equivalent? wchar_t isn't even universally accepted and the char32_t standard was implemented in 2011 to deal with that issue.
|
|
|
|
|
Assuming the basic types are fundamentally correct, else it would have crashed anyway, all it needs is a cast. And it meerely takes a minute or two to read up the types if you are in doubt. Posting a question to a forum is lazy, and NOT the behaviour of an engineer.
|
|
|
|
|
Off-by-one errors, as the simplest form of error in possibly computing history, would like to have a word with you. Sometimes being blind to your own code or simply being ignorant of the context of your code is a fatal mistake. It is in this time of need that developers turn to their peers. Not to be berated but to be educated.
|
|
|
|
|
May be he doesn't have a basic understanding of casting, but that doesn't mean you've a reason to insult him, especially given the circumstances as highlighted by Jon.
|
|
|
|
|
|
An obvious red herring but I'll bite. Given other coding experience - yes I would. A single topic in which you are not well-versed is not indicative of a bad developer. QED.
|
|
|
|
|
Being too lazy to do your own research IS an indication of a bad engineer.
It is only when you have researched and boiled a problem down to a single, distinct question, that you seek the help of senior engineers. If I hadn't done that in my early days I would have got a roasting, and rightfully so!
|
|
|
|
|
I agree with that statement. Now answer me this:
How is "my program is telling me a conversion between const char and LPCTSTR isn't available" not a single, distinct question? That's pretty precise from what I see on these forums.
modified 11-Dec-16 5:53am.
|
|
|
|
|
Can you two just hold the conversation for 15 minutes?
I wanna just pop out and get some popcorn ...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I have some "special" brownies. Would you like some?
|
|
|
|
|
Thank you for the offer, but they tend not to like people who transport them across international borders!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
+1 for making me actually lol. That's just an implementation detail; surely you can hack your way past that
|
|
|
|
|
Ah the brownies. You remind me of my University days.
|
|
|
|
|
Not a single question?
This is what he asked "we want to debug GASChedule. But it not starting on visual studio 2015. we got some errors."
He got COMPILE errors. He doesnt even know the difference between compiling and executing!
The OP doesnt have the first clue about what he is doing, hence my deservedly direct reply.
|
|
|
|
|
Try using a const wchar_t . I'm no expert on character encoding but a char is vastly different from a wchar_t . char is based on ANSI, wchar_t is based on Unicode. Hope this helps
|
|
|
|
|
Open up the version before migration in VS 2012 or VS 2010 and it should be fine. Migrating to 2015 will force you to fix the above errors.
|
|
|
|