|
Thanks for the reading material. Your help is appreciated.
-------------------------------
|
|
|
|
|
ThatsAlok wrote:
sfdougl wrote:
Can you point me to something explaining structures in collection classes?
Yeap, just check out this link :-
http://www.codeproject.com/vcpp/stl/[^]
I found an article in the STL that explains Vectors quite well. Thought I would post it in case some else has this same problem.
A Presentation of the STL Vector Container - STL[^]
Thanks Everyone for you help.
-------------------------------
|
|
|
|
|
Alright, I'll take a stab.
The most simplistic form of a record is that provided by an C-structure, it has the advantage of being a fixed size (speed of access). It also means that it may waste memory, because irregardless of the actual size required, you have to allocate enough memory to store (a fixed size for) each record..
You can create a class that reads a record on a per-field basis....
I am sorry, but I can't explane more at this time (it is almost 4AM and my brain just locked up).
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
John R. Shaw wrote:
The most simplistic form of a record is that provided by an C-structure, it has the advantage of being a fixed size (speed of access). It also means that it may waste memory, because irregardless of the actual size required, you have to allocate enough memory to store (a fixed size for) each record..
Thanks John,
If I understand your post correctly that’s more or less what I did initially to solve the problem. A struct controlled by a class, but it just “felt” incorrect.
John R. Shaw wrote:
I am sorry, but I can't explane more at this time (it is almost 4AM and my brain just locked up).
Don’t worry, I have been toiling over this for a few days now. I'm in no real hurry, the boss is used to me laughing at his ridiculous deadlines.
Thanks for you input.
-------------------------------
|
|
|
|
|
|
Okay, will do, Thanks Ravi
-------------------------------
|
|
|
|
|
create a new mfc sdi project, in onDraw fuction add the following:
pDC->SetDCPenColor(RGB(0,0,0));
when compile, this error happens:
error C2039: 'SetDCPenColor' : is not a member of 'CDC'
according to msdn, CDC has this member. when i input these, there is even a auto completion.
how could this happen?
|
|
|
|
|
Requirements
Windows NT/2000/XP: Included in Windows 2000 and later.
Windows 95/98/Me: Unsupported.
1) Are you using Win 9x?
2) The code for SetDCPenColor is wrapped using
#if (_WIN32_WINNT >= 0x0500)
so you'd need to set the _WIN32_WINNT constant to at least 0x0500 (which should be the constant for Win2K) in the stdafx.h file in your project.
 Pssst. You see that little light on your monitor? That's actually a government installed spy camera. Smile and wave to big brother!
Painted on the side of a dog trainer's van: SIT HAPPENS
|
|
|
|
|
set 0x0500 works.
thanks.
|
|
|
|
|
What version of the IDE are you using, because SetDCPenColor() does not exist.
CPen pen(PS_SOLID,1,0);
CPen* pOldPen = pDC->SelectObject(&pen);
... draw something
pDC->SelectObject(pOldPen)
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
Ok- basic question:
Ive downloaded source files and the accompanying .ocx file for use in a basic visual c++ project. The .ocx file works.
Now- when i edit the source files a bit to add new functuality, how the heck do I recompile them using visual studio into a brand new .0cx file??? Im lost on this aspect.
rich
|
|
|
|
|
The same way you would any other program or dll.
If it came with a VC project file then that should not have a problem.
If it did not and it is VC code, you could try:
1) Create a new ALT COM AppWizard project, with the same name as the current ocx.
2) Add your files to the project. This will involve replacing the app-wizard generated files with your files.
3) Goto the project settings, find output file name (under the link tab) and replace the .dll extension with the .ocx extension.
4) Compile.
Suggestions (before you try above):
1) Create a simple ocx project, to get used to the process.
2) Try the above with copies of the original files, before using your modified files.
P.S. Andrew W. Troelsen is the author of a book on creating ALT COM (ocx) controls.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
1) Compile UNICODE version of app.
2) Copy character U+0428 from Character Map program.
3) Paste character in edit control, no problem.
4) Paste character in rich edit control, no problem.
5) Get text from edit control (TCHAR txt[128]):
txt[0] = 1064, txt[1] = 0;
6) Get text from rich edit control (TCHAR txt[128]):
txt[0] = 63, txt[1] = 10, txt[2] = 13;
Ok! What happened here?
The reverse is also true:
1) Set text in edit control (t[0]=1064,t[1]=0), no problem
2) Set text in rich edit control (t[0]=1064,t[1]=0), a problem. It displays '?', which is character 63.
Any ideas?
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
Maybe try calling EM_GETTEXTMODE and find out if the contorl somehow got set to using ANSI instead of Unicode. It seems that thecontorl might accept any text, but when you retreive the text, it will return text in the format set with EM_SETTEXTMODE. Also, perhaps text should bet set to it with EM_SETTEXTEX instead of WM_SETTEXT.
|
|
|
|
|
Thanks! There does not seem to be a wrapper in the MFC control class for that one.
Text mode = TM_MULTICODEPAGE|TM_SINGLELEVELUNDO|TM_RICHTEXT;
The only thing I can determine from that, is that text is in richtext format. I believe that the rich edit control is entirely UNICODE internaly.
I am using GetRichEditCtrl().ReplaceSel(_T("some text")) only, to send text to the control.
I am using GetRichEditCtrl().GetLine(0,ubuf,128) only (as test), to get text from the control.
GetLine() retrieves wchar_t characters, but they are being translated to ANSI characters, when copied to the wchar_t array passed as an argument.
There is the possibility that it is a local problem, but that makes no since.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
|
I was just wondering, what is the proper way to embed data files within an exe in the VC++ development enviornment. I'd like to do it in a way that would allow the data to be accesed with a simple pointer if possible.
|
|
|
|
|
Goto the resource window, right click and select import.
After it is imported you can get access to the data via its resource id number.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
Isn't there a way to feed the data file to the linker directly via a custom build setup? I'm trying to write my code so it'll be platform independant, so I wanted to avoid getting the windows resource sceme involved. Is there maybe just little command line app that can generate a VC++ compatible obj from a data file or something?
|
|
|
|
|
The minute you depend upon a specific linker option to do something like this, your code become platform dependent.
I don't know if there is a command line app does what your asking. If there is and you use it, then you're again, making your code platform dependent.
Here's how I to do it, when I needed to import such data files into my code:
1) Write a small program that takes my data file type and generates a file that contains an array in C/C++ code, that contains the data.
2) Include the generated file in the project.
That's all there is to it. Now the name of the array is a pointer to your imported data.
Good Luck!
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
>The minute you depend upon a specific linker option to do something like this, your code become platform dependent.
Well, compiling and linking is always a platform dependant proccess isn't it? The issue here is the ease in which you can get an app set up to build on different platforms. Right now all I really concerned about is that all my C code is platform independant. If it's a little tricky to build so be it, I'll cross that bridge when I come to it.
>I don't know if there is a command line app does what your asking. If there is and you use it, then you're again, making your code platform dependent.
That depends. If the app I used was also platform independant, then it wouldn't be a problem.
>Here's how I to do it, when I needed to import such data files into my code:
1) Write a small program that takes my data file type and generates a file that contains an array in C/C++ code, that contains the data.
2) Include the generated file in the project.
>That's all there is to it. Now the name of the array is a pointer to your imported data.
A little messy, but not a bad idea. I'll take it into consideration if I can't find a way to do it the way I wanted. I was thinking I might see if there was a way to rig it up with NASM, but of course then I'm becoming CPU dependant. That isn't actually a real problem at the moment, but it could come back to haunt me later. Hmm... am I the only one who thinks that C needs a standard directive for embedding a data file into a compiled program?
|
|
|
|
|
Xzyx987X wrote:
compiling and linking is always a platform dependent process isn't it?
Yes, compiling and linking are alway platform dependent. What I was referring to, was dependents on a particular linker option; which limits you to only linkers that have that option.
Xzyx987X wrote:
That depends. If the app I used was also platform independent, then it wouldn't be a problem.
If the app produces .obj files, then it can't be platform independent. It would have to know the format of every .obj file produce by every compiler out there (not possible).
Xzyx987X wrote:
I'll take it into consideration if I can't find a way to do it the way I wanted.
In the time it took you to receive and reply to my last message, I could have written the require program (and so could you).
Xzyx987X wrote:
Hmm... am I the only one who thinks that C needs a standard directive for embedding a data file into a compiled program?
Probably.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
See if this article helps.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
I'd rather not do anything that involves hacking up the exe once it's compiled. Talk about a messy build process...
|
|
|
|
|
I'ma C++ newbie, and i'm trying to find a useful occasion where copy constructors can be used. It's quite useless learning the thing and then not knowing when or what to use it for.
MO money, mo problems
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
