Canada has long been a favourite place although I have not spent nearly enough time there. My brother lives in Toronto, about 10 minutes drive from CodeProject HQ (according to Google). Visited there in 2008 for a wedding, and also went up to Manitoulin island to stay with an aunt for a few days. I visited Vancouver a number of times in the 60s while working on a merchant ship. Went back in 2014 for another wedding, and was reminded why I love that city and its environs. Sadly it's a bit late to think about emigrating, and all my, and my wife's, immediate family are close at hand here.
If you move your main to a different CPP file you will run into errors.
But not too difficult to fix with a little thought. The problem is that the implementation in stack.cpp is still a bunch of templates, so when compiled it does not generate any code. I discovered this by generating the assembly listing. So I added the following dummy function to stack.cpp which instantiates one of every template function and it compiles and links cleanly.
Oh, and I missed the part in the original which said "do not amend stack.h unless you see any mistakes". The mistake of course was all those lower case 't's in the templates. Changing them to upper case fixes it.
So my take home is that I learned a few useful things, including how not to use templates. But I think the test was valid as it is a good challenge for the candidate. Had he got it right it would probably have created an opportunity to discuss the whole thing with the people who devised the test. I don't think they are as dumb as first appears.
TimePoint SysTickTimer::Now() const
if(available_) // previously set based on whether high-frequency timing is available
return TimePoint(now.QuadPart); // the current time in ticks (64 bits)
else // will only have millisecond accuracy
auto msecs = 1000LL * now.time;
return TimePoint(msecs + now.millitm);
My Windows 10 installation, running on a Dell XPS15, has 10^7 ticks per second (1 tick = 0.1 usecs). This is determined by
I have a CDialog derived dialog which has a CFormView derived member which has a number of CEdit derived controls placed on it.
Based on business rules at runtime one of the CEdit derived controls should receive the focus when the dialog is displayed. In the OnInitialUpdate override of the CFormView derived class the specfic control is determined and focus is set to that control with the following call:
When the dialog is displayed there is no caret displayed within the control. It is outlined in the blue colour showing that it has focus, if I start typing the text is displayed but still no caret. If I TAB to the next control the caret is displayed there and if I TAB back it is now displayed in the originally focused control.
Alternatively, after the dialog is initially displayed and the caret is not showing If I shift the active window to another app (e.g. visual studio) and then actiavte the app again then the caret does appear in the CEdit control.
Any suggestions as to how I can ensure that the desired CEdit control receives focus on display of the dialog and that the caret is displayed?
I stated that the focus edit is being set from the OnInitialUpdate override of the CFormView derived class, I should have clarified that this has been called from the CDialog OnInitDialog method via a call to