Click here to Skip to main content
15,035,866 members

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

David O'Neil 29-Jan-21 11:42am View
   
So it isn't just a non-understanding on my part, but a limitation of DataGridView. Thanks! And thanks for the link.
David O'Neil 27-Jan-21 14:52pm View
   
Thanks. Not much help in that link, but at least I know I'm not alone...
David O'Neil 1-Sep-20 20:39pm View
   
Windows 7 will remain the pinnacle of Microsoft's UI design. So sad that they have gone so far downhill since then. :(
David O'Neil 31-Aug-20 21:35pm View
   
Thanks. I'll wait before accepting the answer to see if anyone else knows a way to force Win7 behavior through the ways I've tried, but you are probably right.
David O'Neil 31-Aug-20 20:45pm View
   
After thinking, I believe my buttons ARE taking on the styling of Windows, but it is the fugly flat styling of Win10. Blech!!! Is there a way to force it to the rounded styling of the glory days of yore?
David O'Neil 19-Jul-20 22:56pm View
   
Thanks! Great addition to the conversation!
David O'Neil 14-Jul-20 3:47am View
   
If life was so simple! :)
David O'Neil 14-Jul-20 3:45am View
   
The question was why isn't C++ capable of determining that the BaseItem 'str' function matches the requirement. I thought it should be able to.
David O'Neil 14-Jul-20 3:30am View
   
Thanks! CPallini found the exact reason, but I '5'd this for the info!
David O'Neil 14-Jul-20 3:28am View
   
Thank you. That's what I was looking for. Did not know name lookups were restricted this way, so learned something new tonight!
David O'Neil 14-Jul-20 3:15am View
   
You are correct that giving it an argument gives an error for the other reason. It is also interesting that making the derived class's 'str' function virtual doesn't fix the issue, but gives another 'doesn't take 0 args'. The only two ways to fix it is 1) as I did in the original example, 2) create a virtual function in the DerivedItem class that just returns the BaseItem function. Kinda ugly. I thought C++ name lookups were more powerful than this, but then again, I've never faced this situation before.
David O'Neil 5-Feb-20 15:36pm View
   
>> (which for some obscure reason I couldn't do from 8.0)

I believe I remember why: 8.0 didn't have the Windows store, and you had to have that in 8.1 to get the upgrade! :Big Raspberry:

I had 8.1 for a while and was happy with it. Got it working almost exactly like Win7 without Aero. Still miss Aero. :( The hodge podge of design ideas in 10 isn't close to being as comprehensively thought out as 7 was with Aero.
David O'Neil 5-Feb-20 5:24am View
   
Took the plunge and reinstalled Windows. Got VS running again, and there are no more issues! And C drive is over 70 GB freer than it was, although I've still got to reinstall a bunch more. Don't know that it will be 70 GB worth, though!

Thanks for the help, and the time you guys took to set up and run the samples on your end! Just hearing that I wasn't missing something obvious was a relief!
David O'Neil 5-Feb-20 5:19am View
   
I had Win 10, which came from the free upgrade from the 8.0 -> 8.1 that came with the machine. I really didn't want to spend the time setting everything back up again, but I'm almost done installing Office and a couple other main items. Getting everything back is going to be a lot more work, but I'll just install as needed.

Now that I've got it up, is there any reason not to upgrade to Visual Studio 2019 permanently? I saw that it added about 12 KB to my >2 MB executable, but that isn't very worrying unless it is all telemetry.
David O'Neil 4-Feb-20 14:03pm View
   
I just created the above project on another computer and it works fine. I'm leaning towards a reinstall of Windows on my main box, but for now I'll just ignore the exception and carry on. On the plus side, with a reinstall I should be able to use an old Win8 pro license to get Win10 pro on it, instead of Home. And the accumulation of 5 years of stuff will be cleaned out. On the negative: all the time reinstalling everything. Blech!
David O'Neil 4-Feb-20 6:17am View
   
And the disassembly view. The cursor is at the last cmp line:

006B1DED  mov         dword ptr [ebp-244h],0  
       tofn.Flags = OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST;
006B1DF7  mov         dword ptr [ebp-23Ch],1800h  
       GetOpenFileName(&tofn);
006B1E01  mov         esi,esp  
006B1E03  lea         eax,[tofn]  
006B1E09  push        eax  
006B1E0A  call        dword ptr [__imp__GetOpenFileNameW@4 (06BB000h)]  
006B1E10  cmp         esi,esp  
David O'Neil 4-Feb-20 6:06am View
   
After downloading from the MS symbol servers, the call stack is at ntdll.dll!RtlImageNtHeaderEx(), if that is a useful clue.
David O'Neil 4-Feb-20 5:51am View
   
Thank you guys! I changed it to WCHAR and nothing nothing changes in the running. (Yes, it is Unicode.) I'll install VS on my other computer and see if it craps out there. The assembly view shows the following, with the cursor at the last line when the exception occurs, but I've never mastered assembly:

77B7432F  je          _RtlCaptureStackContext@12+5D7Ch (77BCEE9Ch)  
77B74335  mov         dword ptr [edx],ecx  
77B74337  mov         ebx,dword ptr [ebp+8]  
77B7433A  test        ebx,0FFFFFFFCh  
77B74340  jne         _RtlCaptureStackContext@12+5D7Ch (77BCEE9Ch)  
77B74346  mov         eax,dword ptr [ebp+0Ch]  
77B74349  test        eax,eax  
77B7434B  je          _RtlCaptureStackContext@12+5D7Ch (77BCEE9Ch)  
77B74351  cmp         eax,0FFFFFFFFh  
77B74354  je          _RtlCaptureStackContext@12+5D7Ch (77BCEE9Ch)  
77B7435A  mov         edi,dword ptr [ebp+14h]  
77B7435D  test        bl,1  
77B74360  je          RtlImageNtHeaderEx+0DDh (77B743CDh)  
77B74362  xor         bl,bl  
77B74364  mov         esi,dword ptr [ebp+10h]  
77B74367  mov         dword ptr [ebp-4],ecx  
77B7436A  mov         edx,5A4Dh  
77B7436F  cmp         word ptr [eax],dx  
David O'Neil 3-Feb-20 13:11pm View
   
Thanks for the response. I'll see what I can do.
David O'Neil 3-Feb-20 12:29pm View
   
Unfortunately, the Call Stack window just has three lines in it.
ntdll.dll!77e7436f()
ntdll.dll![Frames below may be incorrect/missing...
[External Code]

I don't know how to use that info to solve the riddle. Can you put a memory breakpoint on that 77e7436f somehow, which seems to be a function?
David O'Neil 3-Feb-20 12:06pm View
   
The realist in me thinks that, too. I just don't want to listen to him! I remember how hard it was last time to track one of those down! Stripping away a piece at a time... Uugh!
David O'Neil 2-Feb-20 16:49pm View
   
Thank you. Both projects in the solution are set for Unicode. Changing it to the _T macro didn't make a difference. But it was worth a shot!
David O'Neil 2-Feb-20 16:41pm View
   
Thank you for trying. It encouraged me enough to try the 'Fix' option in the VS installer. Still gives an error. So I downloaded and installed 2019 and built the project with it. It still gives the same issues (or at leas the first execution did the same thing as before).

So either my Windows installation has something screwy in the core (because of the 1903 update?, which did occur between the good and bad runs), and needs reinstalled, or changes to other parts of my framework have a bug somewhere. Yay! I'll try building it on another computer and seeing if that works. I don't relish the thought of reinstalling everything.

Again, Thanks!
David O'Neil 13-Jun-19 1:23am View
   
Deleted
Is TakeInput overriding some MonoBehavior::TakeInput routine? If so, maybe something like: if (MonoBehavior::TakeInput(GetKey(KeyCode.W)) ..., or something like that is what you are after.
David O'Neil 24-Jan-19 17:52pm View
   
What result don't you understand?
David O'Neil 26-Nov-18 17:44pm View
   
So you are passing a pointer 'into' your shared memory block, then accessing that shared memory within the same program to retrieve that 'pointer', and then accessing the memory pointed to by that 'pointer.'

What happens if, instead of storing it as a pointer in the shared memory, you reinterpret_cast it and store it as a DWORD (assuming 32 bit) in the shared memory, and then reinterpret_cast that DWORD back to a pointer in your main program once you retrieve it?

Have you tried passing the pointer directly to the receiving class without using the shared memory, and then comparing how that works compared to the shared memory approach?
David O'Neil 21-Nov-18 18:37pm View
   
You need to be clearer. Are you trying to incorporate an anti-pirating system created in C# in a C++ app? Are you trying to create a splash screen describing your licensing, as in the Afzaal's comment? Something else?

A good place to start is with the documentation that comes with the C# code - what does it say? Do they have help forums? If so, go there, not here.
David O'Neil 30-Oct-18 12:36pm View
   
Deleted
https://www.mbopartners.com/blog/gross-income-vs.-net-income-what-is-the-difference

From it, and many others, gross is the amount *before tax*
David O'Neil 30-Oct-18 12:21pm View
   
Deleted
You got confused. A 50% tax on $150 would be $75, as per my formula. Your formula results in a 33.3% tax rate. (I think you were trying to think of the formula grossSalary = netSalary / (1 - taxRate).
David O'Neil 30-Oct-18 2:49am View
   
>> I believe you intended to be helpful.
I'm glad you can see that. Have a great day!
David O'Neil 29-Oct-18 12:17pm View
   
In other words, he has 'liberated' his mind from the constraints that shackle us lesser mortals! Good for him! :)
David O'Neil 29-Oct-18 11:46am View
   
"I don't care. They didn't give enough of a sh*t to ask for pointed help, so they got what they got, to paraphrase John Simmons in a way."

If this describes your opinion of the question, then why did you post anything ?

I believe you intended to be helpful.

I am raising my vote to a #3 because I don't think it's fair to apply a double-standard here, when part of the problem is the way the site works, and others have very high rep levels.
David O'Neil 28-Oct-18 22:06pm View
   
What happens when you step through it with the debugger?
David O'Neil 20-Oct-18 11:54am View
   
Oops! I'll try to remember that next time. I guess it makes sense, since 'pre' tags are the only ones that keep indentation correctly for code.
David O'Neil 20-Oct-18 2:00am View
   
#1: Wrap your code in 'code' tags (< code > / < /code >) without the spaces.
#2: Give the error you are receiving when trying to access the DLL using a 64 bit program.
David O'Neil 19-Oct-18 10:24am View
   
In this case the app and its library are really that tightly coupled. It is my Window wrapper: https://www.codeproject.com/Articles/793604/DWinLib-Pretty-WinAPI-Incorporation. I made it into a library for the learning experience, and to see if it would decrease compilation times when the library was stable. I could make it necessary to call a function to access gDwlGlobals, but with the tight coupling I don't see the reasons to do so. If you have more thoughts on the matter, I'd like to hear them.
David O'Neil 19-Oct-18 10:08am View
   
Thanks. It was nice to finally sleep knowing the problem was solved!
David O'Neil 18-Oct-18 16:45pm View
   
Given the solution I just posted, I would value your feedback. Is the approach in my previous response to you a bad one for managing the global library object itself? As I said previously, I'm accessing the library vector through a constant reference, so I don't understand why you state it is a terrible way to use the object when I am using it as you recommend later in the comment.

Thanks!
David O'Neil 18-Oct-18 5:37am View
   
>> The problem is that the A-code returns some temporary data which you only store in a reference...

Unless I missed something, the A-code returns a const reference to the stringsC vector. The B-code then copies an element from that vector into a local string.
David O'Neil 18-Oct-18 5:26am View
   
Deleted
What do you mean? Technically, I'm accessing the vector through a constant reference. Additionally, I just made the library pointer to be gDwlGlobalsLib, and the application uses a gDwlGlobals copy that is initialized like:
...
#include "DwlGlobals.h"
dwl::Globals dwlGlobalsInstantiation;
dwl::Globals * gDwlGlobals; //Now only in application units

int WINAPI _tWinMain(HINSTANCE inst1, HINSTANCE inst2, LPTSTR str, int show) {
gDwlGlobals = &dwlGlobalsInstantiation;
...

But it still blows up.
David O'Neil 18-Oct-18 4:42am View
   
Technically, it is an element of the global object, but should be no difference, especially since it works as a non-library project:

namespace dwl {
class Globals {
private:
Strings stringsC;
public:
const Strings & strings() const { return stringsC; }
};
}
David O'Neil 18-Oct-18 4:29am View
   
(and I've placed a breakpoint in the Strings destructor, which isn't tripped)
David O'Neil 18-Oct-18 4:26am View
   
const Strings & strings() const { return stringsC; }
David O'Neil 11-Oct-18 3:48am View
   
As you can tell, I was seriously stumped until after your post. The compiler error wasn't helpful at all to me, especially since the whole section of code seemed to work previously, except I had to move a definition out of the header and into the cpp file! You didn't solve it, but you certainly helped speed me towards the solution - thanks!
David O'Neil 10-Oct-18 16:51pm View
   
Don't know why you think you've been took, but thanks for the pointer. -5- for it - it helped get me to the answer I posted below. Thanks!
David O'Neil 10-Oct-18 16:00pm View
   
>>const string s1 = strings.vecRef[0]; //No Go

>>Look at the definition for vecRef, it is a function that returns a reference to a vector, not astring.

As 'vecRef' does return a reference to a vector, can't you use operator[] on that reference to get at the individual strings? That is what has me perplexed. (Unless, somehow, the compiler is saying that the vector and strings are private to the originating class somehow. But the error code doesn't make sense in those terms.)
David O'Neil 30-Sep-18 0:14am View
   
Interesting, thanks. I'd never heard of it before, and it isn't in the English dictionary I have.
David O'Neil 30-Sep-18 0:05am View
   
Yes, if you want to save processing later.

ps - 'concentated' isn't a word - you probably meant 'compounded'
David O'Neil 29-Sep-18 23:30pm View
   
>> This makes it extremely difficult to use a middle name column.
Processing for 'IsNull', or its equivalent, is not very difficult, in order to build the full name on the fly. If you want to eliminate that processing at query time, you can create a 'fullname' column and populate it after the user verifies first, middle, and last, and save those to independent columns for simpler processing, for a total of four columns. And let them use multiple names in each column, for instances where someone is actually called Mary Sue Kendall Jenkins-Taylor.
David O'Neil 1-Sep-18 1:28am View
   
What are you searching? A database? Something else? You will need to be far more specific in your question.
David O'Neil 22-May-18 9:44am View
   
You're right! I forgot to capitalize my object name! :)

Unfortunately the above is probably the path this unPadawan will follow (if he makes it). Maybe I'm wrong, though. And he learns to craft good questions after trying things out for himself (or herself). Should have just told him to turn it in as-is! ;P
David O'Neil 22-May-18 9:37am View
   
Are all the buttons in the row called 'ibut_Edit'?
David O'Neil 19-May-18 15:14pm View
   
You will not get your homework done here. When you get to a point where your Dispatcher class is giving you problems, you can post the difficulty, and what you have done at that point.
David O'Neil 28-Mar-18 14:02pm View
   
Yeah, it cost me a day. Lesson learned? I've added another configuration to the solution that has 'Debug' and 'Do Logging' enabled. Had a bit of frustration because when I added it, both the Debug and Release configurations switched to 64 bit! And couldn't quickly see how to fix it - thought I was going to have to recreate the entire solution! But figured it out.
David O'Neil 28-Mar-18 10:46am View
   
Thanks for the response, Jochen. I got some sleep, then simply put logging calls in at each step. And after they were installed it started working the way I thought it should. So I played around some more with the logging.

Eventually, it hit me. The library project had DWL_DO_LOGGING defined, and the main application didn't. So the extra 'logger' in the library global was throwing off the address! Duh!!! Back to my universal header!

Have a '5' for your time! Thanks!
David O'Neil 23-Mar-18 12:48pm View
   
Thanks!
David O'Neil 22-Mar-18 17:28pm View
   
That's what I guessed, which I wasn't interested in. Have performed too many calls to 'GetClientRect' that way... Boring...
David O'Neil 22-Mar-18 17:26pm View
   
Thank you! In which cases can the compiler not use NRVO?
David O'Neil 22-Mar-18 16:32pm View
   
Can you show an example, or point to a site that shows the technique in C++?

Thanks!

Or are you saying that it is where the caller sends the address to be filled in in the arguments? I am not looking for that type of solution.
David O'Neil 18-Mar-18 23:33pm View
   
Where is the end of your 'For' statement?
David O'Neil 12-Mar-18 17:59pm View
   
Thx, although all it was in this case was being a second set of eyes.
David O'Neil 27-Apr-17 13:06pm View
   
>> and 1829/890020 is closer than yours. :)

Fortunately, not part of the requirements! :)

>> weird: it is odd to have all numerator a power of 10 apart of the first one.

That is the clue I was talking about. The technique may be the fastest available method to come up with a decent fractional approximation. I could make the denominator 9, 99, 999, 9999, etc, without too much more work, for a little more accuracy. The code only relies upon std functions for printing. No other external libraries used.
David O'Neil 27-Apr-17 5:04am View
   
Define 'weird' more precisely. All of the fractions are close approximations to the desired numbers. In fact, the one for 0.00205501 is closer than Chris's approximation.
David O'Neil 27-Apr-17 4:48am View
   
For now, point B:
Results:
.333, 1: 0 1/3
.125, 2: 0 10/80
.00205501, 6: 0 1000/486616
pi, 2: 3 10/71
pi, 3: 3 100/706
pi, 4: 3 1000/7063

That gives a clue as to the method.
David O'Neil 27-Apr-17 3:39am View
   
Maybe you like #8 better? :)
David O'Neil 22-Apr-17 1:42am View
   
:)
David O'Neil 14-Jan-17 21:02pm View
   
Conceptualize a 3d array in your head. I haven't stepped through your code, but you seem to be trying to treat part of it as a 2d array for your first step. And if I understand it correctly, you are treating a 2x3 array as a 3x2 array, which aren't the same. Before fixing that, I don't believe you can convert a 3d array into a 2d array the way you believe you can. Next, as you've defined the array, it is already linear in memory, if you want a master trick. But your teacher probably wants you to create a second linear array in memory, to show that you understand pointers. When doing so, you need to copy values out of the existing array by using the [][][] nomenclature, not pointer nomenclature, if you want to keep it simple. (You can use pointer nomenclature when you know what you are doing, but it will be much different than what you have. Use the [] method to master it first.)
David O'Neil 14-Jan-17 20:43pm View
   
You will need to provide a lot more detail to get any help here. Where are you getting stuck at? Keep in mind that probably nobody here is in the mood to do your homework for you, but if you are specific in your question you will probably receive an answer, if you show that you are trying.
David O'Neil 1-Dec-16 20:22pm View
   
I like the the simplicity of your COBOL solution! I can see a C++ STL equivalent in my head that would be a little longer, but keep your simplicity. Out of curiosity, can you determine how fast your routine compares to Graeme's output for Solution 10 on your machine? I'm just curious how efficient intrinsics are - I've never played with them.

Your "REPLACING "poo" BEFORE INITIAL "p**"" comment triggered my new approach to solving that part of the problem - without recursion! Thanks!
David O'Neil 1-Dec-16 11:28am View
   
Deleted
My code is ~11.5x as fast as Graeme's revised code on my machine, instead of 13x.
David O'Neil 3-May-16 15:02pm View
   
Doh! Thanks for catching that. It is working. Don't know why the original stopped in VS2015, but have other things to do that are more important than spending more time on it.
David O'Neil 2-May-16 22:26pm View
   
Thanks for the reply. That makes sense, but may not solve the const problem, because the error was on the lambda function line.
David O'Neil 2-May-16 18:43pm View
   
Bling's proposed solution resulted in a fix that runs without issues, so it is highly doubtful that other code is responsible. It appears to be a 'const' issue as I touch upon in my response to him. But if I have a chance, I will work up a minimal project that exhibits the issue.

Thanks for the response.
David O'Neil 2-May-16 18:38pm View
   
Entering the following gives a clue as to what is happening:

wString toUpper(const wString & str) {
wString c;
c=str;
for (auto & c: str) c=std::toupper(c); //ERROR HERE
return c;
}

That gives "... error C3892: 'c': you cannot assign to a variable that is const", so somehow it is turning const.

Rewriting it like the following threw an error about function body redefinition:

wString toUpper(const wString & str) {
wString c(str);
wString::iterator it;
for (it=c.begin(); it!=c.end(); ++it) {
*it = std::toupper(*it);
}
return c;
}

Moving the body into the CPP file instead of the header fixed it.

If you can answer why Visual Studio 2015 is being more aggressive at making things const, I'll mark yours as the solution because it resulted in a method that works.

Thanks much for the pointer, even though I still don't understand why the earlier code didn't simply recompile in 2015 without execution issues, as before.
David O'Neil 2-May-16 9:42am View
   
It will be a std::string or a std::wstring, depending on the definition of UNICODE.
David O'Neil 2-May-16 9:26am View
   
I just tried _totupper, and there is no difference in release: the program crashes. Weird. Thanks for the thought, though.
David O'Neil 2-May-16 8:48am View
   
Checking the address of a heap variable around that point in the code, I get 19EA79 in release mode, so it isn't that far from the address space, but you could be right. The fact that my workaround seems to have eliminated the problem, and everything is running, indicates the 'toUpper' call really is the issue. While debugging, I placed a MessageBox before and after the call, and it passed the first MessageBox before crashing.
David O'Neil 2-May-16 8:41am View
   
Thanks. It is puzzling!, and has made for far too long of a day already.
David O'Neil 2-May-16 8:08am View
   
I've updated the question with error code info. As you will see, it is simply refusing to let my program rewrite the memory locations in the std::transform call in release mode.

Thanks for your help.
David O'Neil 28-Sep-14 9:28am View
   
5-d and Accepted. For clarity, the specific subpage is http://msdn.microsoft.com/en-us/library/aa381033.aspx, where it says (paraphrased) "'#define' in a Resource Compiler file defines a specified name by assigning it a given value." It continues on to say,

"RC treats files with the .c and .h extensions in a special manner. It assumes that a file with one of these extensions does not contain resources. If a file has the .c or .h file name extension, RC ignores all lines in the file except the preprocessor directives."

Thanks for pointing my in the right direction!
David O'Neil 28-Sep-14 5:43am View
   
So it is only for the resource compiler itself? That compiler is constrained to using #defines, and somehow maps '103', or whatever number is used to something different than a const int or other declaration, and then the MAKEINTRESOURCE gets hung up on that difference? I'd like to understand that better if you know of any links... (Googling "microsoft resource compiler requires defines" isn't very helpful.) Thanks.
David O'Neil 21-Aug-14 12:10pm View
   
I would rather have an explicitly stated function call than an implicit conversion occur. I've been bitten by things I can't see, therefore I will shy away from the conversion operator now that I know about it.

Thanks for helping me.
David O'Neil 20-Aug-14 15:31pm View
   
Are you sure you added the CSettings unit to your non-test project properly? Are the include directories correct?

PS - I edited your question to use a code block. Please use them in the future. It makes it much easier on us.
David O'Neil 20-Aug-14 14:09pm View
   
Thanks. It isn't under 'operator()' like I expected, but 'implicit' in Stroustrup revealed the location. It is filed under 11.4: conversion operators. Your link was far from being clear to me!

To use the first one: if surrounding class is 'MyDC' and the object instantiation is 'dc': just "dc()" will retrieve the dcC. Or if it is a pointer, "(*dc)()". To be clearer, "someMethodThatRequiresAplainDeviceContext((*dc)());"
David O'Neil 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 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 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 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 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 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 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 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 13-Jul-13 11:33am View
   
Not even that works. Same error.
David O'Neil 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 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 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!