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

Thanks!

Thank you. If you make that a solution, I will accept it as such.

Ahh. So the constexpr evaluation step is performed after the parsing and initial compilation step, whereas the preprocessor macros actually occur - as the name implies - in the preprocessing step? And the Apple code cannot pass through the compilation step. I'm pretty sure your answer is yes, but I will ask it to ensure my comprehension.

Have you ever played with constexpr for this purpose, as I outlined in the question? If not, what are your reasons for not doing so? From what I gather in this response, your answer is that the #ifdef approach for the entire .cpp file is more powerful of an approach than the alternatives, because the entire project can have all of the files for all of the platforms in it, and the #ifdefs encompassing the entire .cpp file (so the corresponding #endif is at the very bottom of the file) ensures that only the .cpp file for the corresponding project is really incorporated.

So it isn't just a non-understanding on my part, but a limitation of DataGridView. Thanks! And thanks for the link.

Thanks. Not much help in that link, but at least I know I'm not alone...

Windows 7 will remain the pinnacle of Microsoft's UI design. So sad that they have gone so far downhill since then. :(

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.

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?

Thanks! Great addition to the conversation!

If life was so simple! :)

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.

Thanks! CPallini found the exact reason, but I '5'd this for the info!

Thank you. That's what I was looking for. Did not know name lookups were restricted this way, so learned something new tonight!

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.

>> (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.

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!

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.

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!

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  

After downloading from the MS symbol servers, the call stack is at ntdll.dll!RtlImageNtHeaderEx(), if that is a useful clue.

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  

Thanks for the response. I'll see what I can do.

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?

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!

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!

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!

What result don't you understand?

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?

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.

>> I believe you intended to be helpful.
I'm glad you can see that. Have a great day!

In other words, he has 'liberated' his mind from the constraints that shackle us lesser mortals! Good for him! :)

"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.

What happens when you step through it with the debugger?

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.

#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.

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.

Thanks. It was nice to finally sleep knowing the problem was solved!

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!

>> 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.

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; }
};
}

(and I've placed a breakpoint in the Strings destructor, which isn't tripped)

const Strings & strings() const { return stringsC; }

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!

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!

>>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.)

Interesting, thanks. I'd never heard of it before, and it isn't in the English dictionary I have.

Yes, if you want to save processing later.

ps - 'concentated' isn't a word - you probably meant 'compounded'

>> 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.

What are you searching? A database? Something else? You will need to be far more specific in your question.

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

Are all the buttons in the row called 'ibut_Edit'?

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.

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.

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!

Thanks!

That's what I guessed, which I wasn't interested in. Have performed too many calls to 'GetClientRect' that way... Boring...

Thank you! In which cases can the compiler not use NRVO?

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.

Where is the end of your 'For' statement?

Thx, although all it was in this case was being a second set of eyes.

>> 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.

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.

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.

Maybe you like #8 better? :)

:)

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.)

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.

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!

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.

Thanks for the reply. That makes sense, but may not solve the const problem, because the error was on the lambda function line.

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.

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.

It will be a std::string or a std::wstring, depending on the definition of UNICODE.

I just tried _totupper, and there is no difference in release: the program crashes. Weird. Thanks for the thought, though.

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.

Thanks. It is puzzling!, and has made for far too long of a day already.

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.

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!

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.

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.

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.

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)());"

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).

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!

>> 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.

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!

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!

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!

I will make it so, and yes it is. Thank you very much for your time and knowledge!

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.

Not even that works. Same error.

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 < >)

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

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!