Click here to Skip to main content

Comments by David O'Neil (Top 12 by date)

David O'Neil at 23-Jun-14 11:31am View
   
You now have CFileDialog set up correctly to use wchar_t under the hood for your Unicode build, but you (or someone else) has programmed ParseFile to use a char array instead of a wchar_t array for the filename passed to it. The proper way to solve that would be to change ParseFile to take 'TCHAR *' for its argument, not 'char *', and then modify ParseFile appropriately. The link given by Sergey should help you understand what is going on under the hood better, but basically if you are building a Unicode build, TCHAR is a macro that expands to wchar_t, and if you do a Multi-byte build, TCHAR expands to char. If you use TCHAR everywhere, your program can be built for Unicode or Multi-byte without any problems (usually).
David O'Neil at 13-Jun-14 5:27am View
   
The report went through and MS has confirmed the buggy behavior. Time for some sleep!
 
Interestingly, the unit that this reared its head on now refuses to have any in-header initializations in it without buggy behavior. Made for a rather long initializer list (25 members) - yuck!
David O'Neil at 13-Jul-13 17:34pm View
   
>> You just have to find the most acceptable solution when you face a problem like this. Unfortunately its not always as clean as in this case.
 
And it sure is frustrating when what you had worked in an earlier compiler! But things like this are those which give insights into the craft. Again, thanks to you, as well as everyone else.
David O'Neil at 13-Jul-13 14:42pm View
   
Thanks for the reminder. It has been a while since I've delved this deep into this stuff. And as far as the buggy code - for an example I won't say a thing! And since you caught it, the chance of getting to production is slim!
David O'Neil at 13-Jul-13 13:55pm View
   
Yes, since I had the MyModalWindow throughout the d = call. But I was too tired to realize that, and the inline idea was fixed in my mind... Again, thanks!
David O'Neil at 13-Jul-13 13:48pm View
   
That is the solution! It was simply in the "d = ... assignment that I needed to make certain everything referred to MyModalWindow, which, if you review the previous code snips, weren't the cases. Doing that, the virtual method ISN'T NEEDED - it can be a regular class function!
 
For clarity, here's the working code for the initial method:
 
class DwlWinObject {
};
 
template <class T>
class DwlDelegate {
public:
typedef void (T::*FuncPtr)(DwlWinObject*);
protected:
FuncPtr ptrC;
public:
int junk;
static DwlDelegate create(T* object_ptr, DwlWinObject * arg, FuncPtr ptr) {
DwlDelegate d;
d.junk = 12;
return d;
}
};

class ModalBaseWindow : public DwlWinObject {
protected:
int a;
void accept(DwlWinObject*) {
int a=0;
}
};

class MyModalWindow : public ModalBaseWindow {
public:
MyModalWindow() {
DwlDelegate<MyModalWindow> d = DwlDelegate<MyModalWindow>::create(this, this,
&MyModalWindow::accept);
int test = d.junk;
d.junk = 15;
}
};

void main() {
MyModalWindow win;
}
 
Of course, that means more rework than making everything public, but that's OK! Thank you very much!
David O'Neil at 13-Jul-13 12:06pm View
   
I will make it so, and yes it is. Thank you very much for your time and knowledge!
David O'Neil at 13-Jul-13 11:46am View
   
By changing the other places appropriately (the typedef and such), it will compile. But you lose the ability to do anything interesting in the accept function unless you resort to static member variables as well.
 
A full-blown solution is to go to the std::function approach I outline in this article, but I'm not ready to take that plunge at this stage. [EDIT] - Now that I think about it, even that probably won't work, because of the same issue - I'm getting tired.[/EDIT] Another, to overcome the static problem, is the one I hinted at in the question:
 
class DwlWinObject {
};
 
template <class T>
class DwlDelegate {
public:
typedef void (T::*FuncPtr)(DwlWinObject*);
protected:
FuncPtr ptrC;
public:
int junk;
static DwlDelegate create(T* object_ptr, DwlWinObject * arg, FuncPtr ptr) {
DwlDelegate d;
d.junk = 12;
return d;
}
};

class ModalBaseWindow : public DwlWinObject {
protected:
int a;
virtual void accept(DwlWinObject*) {
int a=0;
}
};

class MyModalWindow : public ModalBaseWindow {
public:
MyModalWindow() {
DwlDelegate<MyModalWindow> d = DwlDelegate<MyModalWindow>::create(this, this,
&MyModalWindow::accept);
int test = d.junk;
d.junk = 15;
}
inline void accept(DwlWinObject * ptr) {
return ModalBaseWindow::accept(ptr);
}
};

void main() {
MyModalWindow win;
}
 
I suspect the compiler shouldn't be allowing me to specify inline on the accept override, and will really ignore it, and a similar function has to be added to every other derived unit. But at least now I know my options.
David O'Neil at 13-Jul-13 11:33am View
   
Not even that works. Same error.
David O'Neil at 13-Jul-13 10:08am View
   
Thank you for the feedback. Yes, I get the same error regardless of the approach. Even the following gives the exact same thing, whether or not I cast in the d = line. I don't have another compiler installed, and even though it would be fun to play and see, I'm going to skip on that for now.
 
class DwlWinObject {
};
 
template <class T>
class DwlDelegate {
public:
typedef void (T::*FuncPtr)(DwlWinObject*);
protected:
FuncPtr ptrC;
public:
int junk;
static DwlDelegate create(T* object_ptr, DwlWinObject * arg, FuncPtr ptr) {
DwlDelegate d;
d.junk = 12;
return d;
}
};

class ModalBaseWindow : public DwlWinObject {
friend class DwlDelegate<ModalBaseWindow>;
protected:
int a;
void accept(DwlWinObject*) {
a=0;
}
};

class MyModalWindow : public ModalBaseWindow {
public:
MyModalWindow() {
accept(this); //2008: No problem accessing 'accept'
//But VS2012 gives C2248 compile error on the next line.
//C2248 is 'cannot access protected member'
//VS2008 has no problems with it, and executes as expected.
DwlDelegate<modalbasewindow> d = DwlDelegate<modalbasewindow>::create(this, this,
(DwlDelegate<modalbasewindow>::FuncPtr)(&ModalBaseWindow::accept));
int test = d.junk;
d.junk = 15;
}
};

void main() {
MyModalWindow win;
}
 
(And don't ask me why a copy/paste results in ModalBaseWindow loosing its capitalization when inside < >)
David O'Neil at 13-Jul-13 9:17am View
   
You mean something like this?
 
class DwlWinObject {
};
 
class ModalBaseWindow;
 
template <class t>
class DwlDelegate {
typedef void (T::*FuncPtr)(DwlWinObject*);
protected:
FuncPtr ptrC;
public:
int junk;
static DwlDelegate create(T* object_ptr, DwlWinObject * arg, FuncPtr ptr) {
DwlDelegate d;
d.junk = 12;
return d;
}
 
};

class ModalBaseWindow : public DwlWinObject {
protected:
int a;
void accept(DwlWinObject*) {
a=0;
}
};

class MyModalWindow : public ModalBaseWindow {
public:
MyModalWindow() {
accept(this); //2008: No problem accessing 'accept'
//But VS2012 gives C2248 compile error on the next line.
//C2248 is 'cannot access protected member'
//VS2008 has no problems with it, and executes as expected.
DwlDelegate<mymodalwindow> d = DwlDelegate<mymodalwindow>::create(this, this, &ModalBaseWindow::accept);
int test = d.junk;
d.junk = 15;
}
};

void main() {
MyModalWindow win;
}
 
If so, that's also a no-go. I was surprised it took the 'd = line. [edit - I mean that it didn't barf up a template error instead of the 'can't access' error!] Templates make my head hurt!
 
Thanks,
David
David O'Neil at 13-Jul-13 8:06am View
   
Seldom used this before, so didn't see how to comment. But deleted my other reply now that it is abundantly obvious!
 
Unfortunately, friending it doesn't work. I'm seriously thinking about the public route to save time. Thanks for the input!

Advertise | Privacy | Mobile
Web04 | 2.8.140721.1 | Last Updated 1 Jan 1900
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid