|
|
How do get the application path in mfc? I used fopen and CFile to try and open "out.txt" how ever it shows up in the system 32 directory instead of in the .exe running directory, any thoughts?
|
|
|
|
|
Lookup info on GetCurrentDirectory. I think that should get you what you want. There maybe some other SDK functions which are better suited. See if this helps.
|
|
|
|
|
char buf[MAX_PATH+1];
DWORD res = GetModuleFileName(AfxGetInstanceHandle(),
buf,
MAX_PATH);
}
-c
Conservative:
Faith is the quality that enables you to eat blackberry jam
on a picnic without looking to see whether the seeds move.
|
|
|
|
|
|
burn fopen and CFile and use C++ file reading, specifically ifstream.
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
Cats, and most other animals apart from mad cows can write fully functional vb code. - Simon Walton - 6-Aug-2002
|
|
|
|
|
Christian Graus wrote:
use C++ file reading
what does this offer that C-stream I/O (fopen and pals) doesn't? (besides being shiny and new)
-c
Faith is the quality that enables you to eat blackberry jam
on a picnic without looking to see whether the seeds move.
|
|
|
|
|
How can I get a member variable associated with a control on a dialog?
I've used the Class Wizard in an attempt to add a member variable associated with the control to no avail. The only way I can transfer the data from the form to the variable is via 'GetDlgItemText' and 'GetDlgItemText' doesn't work with Radio (AKA: Option) Controls.
All the controls I've placed on the form will not accept member variables with its associated class functions (ie: text box = edit1.text, edit1.GetLength, etc.)
I have to create member variables through the 'Class View' pane and they're not associated with any particular control.
Can anyone help?
(I can do it VC++ 6.0 but not EVC++ 3.0.)
|
|
|
|
|
open the dialog in the resource editor. Select the control. hold the contrl key down and double click. A wizard will appear asking for the name of the variable you want to associate with the control.
|
|
|
|
|
Full of glee I used an edit control to test it out. It didn't work.
I totally believe you; however, all I get is a messagebox saying "There are no data types for this kind of control." MB_OK.
I'm using a dialog interface, if that helps. It's also doing the same thing on my laptop and desktop PC. Does the installation of VC++ 6.0 and EVC++ 3.0 installed on the same machine hinder 3.0 for some reason? I would think not but one never truely knows.
Carl
|
|
|
|
|
Hmmmm. Maybe that's not it...
I tried it on my machine to verify. Hold control key. Double click control in dialog editor. Up comes small dialog asking for member variable name and type.
I don't know about EVC++ 3.0. What is it? Did the dialog editor build a class for the dialog? Can you see it in the Class Wizard?
Maybe the .clw file is hosed. You can try deleting it. Then run the Class Wizare. It will prompt and then rebuild it for you.
Good luck.
|
|
|
|
|
CTRL - click^2 works in VC++ 6.0.
I'm using Embedded Visual C++ 3.0 for WinCE.
I'll try deleting the .clw file and see what happens. ALthough I doubt that will fix it - this behaviour happens on all the PCs I try this with.
Added:
Oh, and thanks for your help. 
|
|
|
|
|
Yeh, I expect that won't help either, just a desperate attempt to sound smart on my part. I did find this on Win CE development, however.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/apcguide/htm/appwzrd_5.asp
It may help. I notice they do NOT refer to the class wizard.
|
|
|
|
|
The CComVariant class in ATL has the following functions
CComVariant(LPCSTR lpszSrc)
{
vt = VT_EMPTY;
*this = lpszSrc;
}
CComVariant& operator=(LPCSTR lpszSrc)
{
USES_CONVERSION;
InternalClear();
vt = VT_BSTR;
bstrVal = ::SysAllocString(A2COLE(lpszSrc));
if (bstrVal == NULL && lpszSrc != NULL)
{
vt = VT_ERROR;
scode = E_OUTOFMEMORY;
}
return *this;
}
Which means the only way to get it to allocate memory for a new object is to use the assignment operator. The following code produces different results
char buf[256] = "test";
CComVariant result = buf;
char buf[256] = "test";
CComVariant result;
result = buf;
discuss!
Todd Smith
|
|
|
|
|
Yeah, that sounds pretty messed up. 
---
Shog9
If I could sleep forever, I could forget about everything...
|
|
|
|
|
Those 2 code snips are equivilent. You can also use
CComVariant result("test");
for the same result.
Tsyntax
CComVariant result = buf;
compiles to the same object as
CComVariant result;
result = buf;
|
|
|
|
|
That's what I thought until my app was crashing and I stepped through the code and discovered otherwise.
this calls the constructor CComVariant(LPCSTR lpcStr)
CComVariant result = buf;
and this calls the assignment operator CComVariant& operator=(LPCSTR lpcStr)
CComVariant result;
result = buf;
I don't know what the C++ standard says about that.
Todd Smith
|
|
|
|
|
No. they all do the same thing. I stepped into them also and thought I saw what you said.
CComVariant result = buf;
executes
#ifndef OLE2ANSI
CComVariant(LPCSTR lpszSrc)
{
vt = VT_EMPTY;
*this = lpszSrc;
}
#endif
CComVariant result2(buf);
executes the same
CComVariant result3;
executes
CComVariant()
{
vt = VT_EMPTY;
}
result3 = buf;
executes
#ifndef OLE2ANSI
CComVariant& operator=(LPCSTR lpszSrc)
{
USES_CONVERSION;
InternalClear();
vt = VT_BSTR;
bstrVal = ::SysAllocString(A2COLE(lpszSrc));
if (bstrVal == NULL && lpszSrc != NULL)
{
vt = VT_ERROR;
scode = E_OUTOFMEMORY;
}
return *this;
}
#endif
Then I looked closer and stepped deeper and found they all ended up executing the = operator code! It does allocate memory.
This line of code from the constructor
*this = lpszSrc;
executes the = operator code shown above. So all come out the same.
The only caveat I see is that you may not have OLE2ANSI defined.
Make sense?
|
|
|
|
|
Ah that's true. The bug ended up being something else anyways
Todd Smith
|
|
|
|
|
No, it does not. These two are exactly equivalent:
CComVariant v ("foo");
CCOmVariant v = "foo";The second line does not construct an object then call operator=.
--Mike--
Just released - RightClick-Encrypt v1.3 - Adds fast & easy file encryption to Explorer
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
Guess again. If you trace through the code you will see it do it.
|
|
|
|
|
Please learn how the language works before making such bold and incorrect statments.
#include <iostream>
using std::cout;
using std::endl;
class C
{
public:
C(int x) : m_n(x) { cout << "in constructor" << endl; }
protected:
C(const C& rhs) : m_n(rhs.m_n) { cout << "in copy constructor" << endl; }
const C& operator = (int x)
{ cout << "in operator =" << endl;
m_n=x; return *this; }
int m_n;
};
int main()
{
C c1 (1);
C c2 = 2;
return 0;
}I even threw in a copy constructor in case you wanted to be a smartass about that. That wouldn't even compile if the c2 declaration were calling the assignment operator. Yet, somehow it does. Look, here's the output:
in constructor
in constructor Good night.
--Mike--
Just released - RightClick-Encrypt v1.3 - Adds fast & easy file encryption to Explorer
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
I'm not quite sure what your point is. It doesn't seem to have anything to do with my post. Did you post this in the wrong thread, or are you simply confused?
This thread was discussing the behaviour of a specific class and its constructors. If you look at the COleVariant class you will see a critical difference between its constructors and the one in your post.
"Please learn how the language works before making such bold and incorrect statments."
For someone who's posts seem to contradict even themselves, THAT is a bold statement. You seem to be both agreeing and disagreeing in the same post, while criticising the whole time. I suggest you re-read the thread more carefully; and learn to look before you leap.
"in case you wanted to be a smartass about that"
Calling me names just reinforces my opinion of your post and may even effect my opinion of you!
|
|
|
|
|
These two lines are not equivalent. Second line is considered equivalent to:
CComVariant v(CComVariant("foo"));
Thus it require that a copy constructor exists is accessible. The compiler was allowed to optimize away useless copy (I'm not sure if this is still allowed by the standard and under which condition --- I think that condition are now more strict).
Thus the first version will always call one constructor (which will in this case call assignment operator after initializing vt to VT_EMPTY to ensure that assignment won't try to destroy an unintialized VARIANT).
The second one may depend on the compiler, optimisations and possible minor changes in the standard. Thus it is preferable to uses the first one if it does mather.
Philippe Mori
|
|
|
|
|
There seems to be some confusion in this thread. I've seen several erroneous explanations based on theories about C++ language definition and VC++ compiler behavior. A simple look at the code shows what is going on.
There is no requirement for a copy constructor. It is needed for CComVariant because of this line in the constructor:
*this = lpszSrc;
That is the ONLY reason. If the coder had duplicated the logic of the = operator in the constructor, this line would not be present and the = operator would not be needed (for this constructor). This has nothing to do with compler optimization.
CComVariant v(CComVariant("foo")); // Uses a temporary object
is equivilent to
CComVariant vTemp("foo");
CComVariant v(vTemp);
not
CComVariant v = "foo";
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
