I rather think it is, "Oh, C++ string handling looks difficult, I'll find a different library". Yes, there is a learning curve but that is true of just about everything. You can probably guess that I have never used boost.
why is it so elephanting difficult to format a string into a buffer in standard C++?
What does that mean exactly? Both 'format' and in general why would you think that something would make it easy.
As I recall as to what I think you are referring in the cases in the past if I had a specific fixed need to put/get values into a buffer then I just wrote a class that did it appropriately. It would have get/set methods that would do the correct thing for the buffer.
Then there were a couple of management methods that set the buffer up, extracted it, etc.
Similar but simpler than the way XML/Json libraries work. And long ago I created at least one implementation that did things similar too those with multiple types and I did it in C++.
For example - suppose I want to format a log message. Beloved printf/sprintf:
sprintf(&buf, "Now is the time (%s) for all good %s blah blah.\r\n", GetTime(), "men");
First I wouldn't roll my own log, but that gets back to your point of not using a library.
So if no library then I would write my own log api, and it would include a varargs log methods (one for each filter type.) And I would just implement a standard varargs method to do the write.
I have done exactly that at least twice before standard log libraries existed.
Why would you write a class for doing something like this?
The examples in the past, to which I thought you might have been referring were in reference to populated a piece of binary data, for message protocols, which must have a very specific format. For example (2 byte positive int, 4 char identifier, 20 char text)
Following up on this, I'll have to dig into that. That approach looks simple enough. Of course, the GetTime was a make believe function. Funny, I would think that I would have seen something like this under "Formatting Text in C++" or what have you. I'll dig for more examples.
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
For some reason the DrawItem gets called repeatedly unit a stack exception occurs
That indicates that your DrawItem implementation might be called recursive (probably not directly but by calling a function that results in a redraw). So check your code for such calls. A drawing function should only draw the control itself and do nothing else like changing properties of the control. If you for example change the selection within the drawing function, that would trigger another redraw.
SetWindowText() sets the text and initiates drawing which must be implemented in your DrawItem function!
Example (copied & pasted, unchecked, unthemed classic method):
void CMyStatic::DrawItem(LPDRAWITEMSTRUCT lpDrawItemStruct)
ASSERT(lpDrawItemStruct->CtlType == ODT_STATIC);
CDC* pDC = CDC::FromHandle(lpDrawItemStruct->hDC);
ASSERT(pDC != NULL);
// Get text format options.
UINT nFormat = m_nFormat;
// get actual settings in case they has been changed
DWORD dwStyle = GetStyle();
// Don't process '&' prefix sequencesif (dwStyle & SS_NOPREFIX)
nFormat |= DT_NOPREFIX;
// vertically centered text and no new lineif ((dwStyle & SS_CENTERIMAGE) && str.Find(_T('\n')) <0)
nFormat &= ~DT_WORDBREAK;
nFormat |= DT_VCENTER | DT_SINGLELINE; // must set both!
if (dwStyle & SS_ELLIPSISMASK)
nFormat &= ~DT_EXPANDTABS; // not supported with ellipsisswitch (dwStyle & SS_ELLIPSISMASK)
case SS_ENDELLIPSIS :
nFormat |= DT_END_ELLIPSIS | DT_MODIFYSTRING; break;
case SS_PATHELLIPSIS :
nFormat |= DT_PATH_ELLIPSIS | DT_MODIFYSTRING; break;
case SS_WORDELLIPSIS :
nFormat |= DT_WORD_ELLIPSIS; break;
// The complete background has just been filled.// So use transparent mode for faster text drawing.// Saving and restoring of colors and mode is not necessary (drawing only performed here).
pDC->SetTextColor(bDisabled ? ::GetSysColor(COLOR_GRAYTEXT) : m_clrText);
// The text string may be modified if DT_MODIFYSTRING is set!
LPTSTR lpszText = str.GetBuffer();
pDC->DrawText(lpszText, -1, &lpDrawItemStruct->rcItem, nFormat);
> 0 The font mapper transforms this value into device units and matches it against the cell height of the available fonts.
0 The font mapper uses a default height value when it searches for a match.
< 0 The font mapper transforms this value into device units and matches its absolute value against the character height of the available fonts.
Not quite sure what the above means but my question is the units sepcfied on the Crect parm of CStatic:Create the same as the units for lfHeight and lfWidth so if the width of my static control
is 20 and I specify 3 for lfWidth and I have 5 characters the would = 15 units
I'm writing a quick options dialog app, but am a little rusty with my MFC. In short, I have a list box to the left and a property sheet containing pages corresponding to the items in the list box. However, I want to hide the tab control of the property sheet and move the pages up to match the top of the list box.
Hiding the tab control is easy: CPropertySheet::GetTabControl()->ShowWindow(FALSE)
I then went down the path of grabbing the rects of things and subtracting, but I can't help but think I'm making this more complicated than it needs to be. (I did this once back in 2005, but don't have that code and can't remember what I did.)
i tryed to get it in c++
its a start
i been programming clasical computers for +-30 year's
i not even shure i wil understad this [ if ever ]
// bluatigro 8 nov 2017// QC sim// see :// https://quantumexperience.ng.bluemix.net/qx/experience
void rot( double & k , double & l , double r)
double s , c , hk , hl ;
s = sin( r ) ;
c = cos( r ) ;
hk = k * c - l * s ;
hl = k * s + l * c ;
k = hk ;
l = hl ;
constdouble PI = atn( 1.0 ) * 4.0 ;
double x , y , z ;
Qbit() // |0>
x = 0.0 ;
y = 0.0 ;
z = 1.0 ;
Qbit( double a , double b , double c )
x = a ;
y = b ;
z = c ;
rot( y , z , PI ) ;
rot( x , z , PI ) ;
rot( x , y , PI ) ;
void H() // |+>
rot( x , y , PI / 2 ) ;
rot( x , y , -PI / 2 ) ;
rot( x , y , PI / 4 ) ;
rot( x , y , -PI / 4 ) ;
return z <0.0 ? 1.0 : 0.0 ;
void cnot( Qbit & control , Qbit & target )
if ( control.get_state() == 1.0 )
target.z = 1.0 - target.z ;
usingnamespace std ;
cout << "Hello world!" << endl;
I try to find out what the best strategy is to create a MFC based application that is dpi-aware. Windows is based on 96 dpi for years. Today there are pc's like the Microsoft Surface that have lot more dots per inch.
In windows you can set the screen scaling factor to 100%, 125%, 150%, etc.
If you build the application with a manifest that set DPI Awareness with High DPI Aware, then the resource templates like dialogs scale automatically. Only the custom drawings must be scaled with extra code
No, your application should work on any screen if it allows Window to scale it correctly. If the screen size is important then you can get the current values from GetSystemMetrics function (Windows)[^].
I must do dialog development in 1024 x 768 pixels at 96 dpi
Dialogs have their own measurement system (dialog units) which is supposed to make them look the same on any screen. But, as I said above, if you magnify to 150% you need to make sure it will still fit in the space you have.