I think, you mean which collection class? If so, Array is more efficient on random access. I also think, you need to access the elements with Primary Keys/Forein Keys in master-detail relationships. If you need rows in sorted order, you can fill this array sorted. You can take advantage of SQL's SELECT with ORDER BY clause while filling. If the array is sorted, you can access its items by using binary search to speed up searches. If you just need to access items by the key, you can simply employ CMap to access its elements with key-value pair. typedef CMap<int, int, CDataPack, CDataPack&> CDataPackMap; You need to keep relationships yourself, or maybe, you may create more sophisticated structures. [edit]BTW, Not at all. :) [/edit]

#include class CDataPack : public CObject
{
public: // you can determine this access scope
CStringArray m_saType;
CStringArray m_saItem;
CStringArray m_saPerson;

const CDataPack& operator=(const CDataPack& rdp)
{
	m\_saType.Copy(rdp.m\_saType);
	m\_saItem.Copy(rdp.m\_saItem);
	m\_saPerson.Copy(rdp.m\_saPerson);
	return \*this;
}

BOOL IsSerializable() const { return TRUE; }

virtual void Serialize(CArchive& ar)
{
	m\_saType.Serialize(ar);
	m\_saItem.Serialize(ar);
	m\_saPerson.Serialize(ar);
}

};

typedef CArray CDataPackType;

void AnyFunc()
{
CString strElement(_T("An Element"));
CDataPack pkt;

pkt.m\_saType.Add(strElement);  // using public access
pkt.m\_saItem.Add(strElement);
pkt.m\_saPerson.Add(strElement);

CDataPackType arrData;

arrData.Add(pkt);

CFile file; // TODO: you need to open the file
CArchive ar(&file, CArchive::store);
arrData.Serialize(ar);

}

If you don't want to use template counterpart, you can also use CObArray or even CPtrArray (or List ones such as CObList, CPtrList, see afxcoll.h). Just beware cleanup of objects.

Resetting sign bit;

__declspec(align(16)) float arrFlt[4] = { -10.0, -20.0, -0.0, -3.0 };
__declspec(align(16)) int mask[4] = { 0x7fffffff, 0x7fffffff, 0x7fffffff, 0x7fffffff };

_asm lea eax, arrFlt
_asm movaps xmm0, xmmword ptr [eax]
_asm andps xmm0, xmmword ptr mask
_asm movaps xmmword ptr [eax], xmm0

Or with intrinsics;

_mm_store_ps(arrFlt, _mm_and_ps(_mm_load_ps(arrFlt), _mm_load_ps((float*)mask)));

bmiColors member of BITMAPINFO is variable sized array. Its size can be zero or more depending on other attributes such as biClrUsed, biBitCount and last parameter of GetDIBits() which can be DIB_PAL_COLORS or DIB_RGB_COLORS. BITMAPINFOHEADER[^] Excerpt from above link. If biCompression equals BI_RGB and the bitmap uses 8 bpp or less, the bitmap has a color table immediatelly following the BITMAPINFOHEADER structure. The color table consists of an array of RGBQUAD values. The size of the array is given by the biClrUsed member. If biClrUsed is zero, the array contains the maximum number of colors for the given bitdepth; that is, 2^biBitCount colors. In our case, 2 ^ 8 = 256 color table entries exist. You may also want to look at BITMAPINFO[^]. If bmpInfo.bmiHeader.biBitCount = 0x01; then it is a monochrome bitmap and color table will have two entries (e.g. RGB(0, 0, 0) and RGB(255, 255, 255)). Color table is array of colors used in the bitmap.

Sooner or later, we are all goners. :cool:

Paul Baran, Internet Pioneer, Dies in Calif. at 84[^]

You can do it by following way. First, you need storage space for color table as being palette entries.

typedef struct tagBITMAPINFO_8BPP
{
BITMAPINFOHEADER bmiHeader;
RGBQUAD bmiColors[256];
} BITMAPINFO_8BPP;

I've used above structure for simplicity. You can also allocate it dynamically as much (sizeof(BITMAPINFO) + sizeof(RGBQUAD) * 255) in bytes. In that case, you need to adjust values in BITMAPFILEHEADER and file write operation accordingly.

...
LPVOID pBuf = NULL;
BITMAPINFO_8BPP bmpInfo; // instead of BITMAPINFO bmpInfo;
BITMAPFILEHEADER bmpFileHeader;

...

bmpInfo.bmiHeader.biBitCount = 0x08; // 8bit,when I use it,bmp is invalid.

...

bmpInfo.bmiHeader.biCompression = BI_RGB;
GetDIBits(hdc, hBitmap, 0, bmpInfo.bmiHeader.biHeight,
pBuf, (BITMAPINFO*)&bmpInfo, DIB_RGB_COLORS);

...

bmpFileHeader.bfReserved1 = 0;
bmpFileHeader.bfReserved2 = 0;
bmpFileHeader.bfSize = sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFO_8BPP) +
bmpInfo.bmiHeader.biSizeImage;
bmpFileHeader.bfType = 'MB';
bmpFileHeader.bfOffBits = sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFO_8BPP);

fwrite(&bmpFileHeader, sizeof(BITMAPFILEHEADER), 1, fp);
fwrite(&bmpInfo.bmiHeader, sizeof(BITMAPINFO_8BPP), 1, fp);
fwrite(pBuf, bmpInfo.bmiHeader.biSizeImage, 1, fp);

...

BTW, beware that list box is already subclassed by other reason. If it paints itself without using windows behaviour, that is, without sending WM_CTLCOLOR notifications to its parent, your attempt can be failed again.

Don't use both. Use 1st one.

LRESULT CComboBoxExt::OnCtlColorListBox(WPARAM wParam, LPARAM lParam)
{
// If the listbox hasn't been subclassed yet, do so
...

// CWnd \*pWnd = CWnd::FromHandle((HWND)lParam);
// UINT nID = npWnd->GetDlgCtrlID();
// nCtlColor = CTLCOLOR\_LISTBOX;

CDC\* pDC = CDC::FromHandle((HDC)wParam);

// move your attributes here
...

return hbr;

}

Yes. This blocks OnCtlColor(CTLCOLOR_LISTBOX). OnCtlColor() (WM_CTLCOLOR) is retained from 16Bit Windows and should be managed by MFC using newer messages like WM_CTLCOLORLISTBOX. You can also use this handler to do your work, the HDC is wParam and you need to return a valid HBRUSH. But, above return value is invalid (as brush). Probably, that listbox should paint itself if this doesn't produce a problem. In this case, how could you paint again?

In above code, that is, subclassed combo box's OnCtlColor() member, you should handle CTLCOLOR_LISTBOX for dropped-down list box. May be, subclassing fails. To ensure that above code is called, put the following line on top of function. TRACE(_T("CComboBoxExt::OnCtlColor() was called with nCtlColor: %d\n"), nCtlColor); And watch output window to see above phrase.

:) I don't know how it could be? Thanks. I will try to put my signature permanently. I remember, seeing you. :) Edit: It again didn't save it permanently. :^)

Time is never on our side! -- Albert Holguin

You need to handle OnCtlColor()[^] in your parent window to check (nCtlColor == CTLCOLOR_EDIT) condition for normal state. You need to subclass CComboBox and handle OnCtlColor() to check (nCtlColor == CTLCOLOR_LISTBOX) condition for dropped down state, that is, while the list box is visible. In this case a child LB is created on the fly. In OnCtlColor() members:

pDC->SetTextColor(clrTextColor));
pDC->SetBkColor(clrBkColor);
if(NULL == m_pBrush)
m_pBrush = new CBrush(clrBkColor); // this is for demonstration purposes
return (HBRUSH)*m_pBrush; // you can handle this brush more convenient way

Don't forget to return HBRUSHes in both cases.

You can simply pass NULL to CDialog constructor as parent window. In this case, MFC searches a proper one. If it doesn't find any, dialog's parent window is set to the main application window. You also don't have to use above constructor for modeless dialog boxes. You can use default constructor then you can specify parent window later by Create() function.

m_pDlg = new CMymfc9Dialog();

m_pDlg->Create(IDD_MYMFC9DIALOG, NULL); // or parent wnd instead of NULL

m_pDlg->ShowWindow(SW_SHOW);

You've forgotten to implement functions.

typedef struct ItemData
{
BOOL bState;
LPCTSTR lpszString;
DWORD dwItemData;
ItemData(LPCTSTR lpsz, BOOL bSt, DWORD dw)
: lpszString(lpsz), bState(bSt), dwItemData(dw)
{

}

virtual ~ItemData() { };
};

Are you aware of this URL? http://xfgr.com/[^] I've checked its domain info but couldn't find anything relevant. :)

I couldn't understand what you want to achieve exactly.

Flaviu 2 wrote:

How can I tell the compiler that should compile only VC6 code ?

If you don't want to compile some codes in later releases than VC6. You can use this guard.

#if _MSC_VER <= 1200
...
#endif

But, your problem seems to be related with SDK version rather than compiler version. If so, (that is, a new feature which is not exist older vers,) you should use other macros such as WINVER, _WIN32_WINNT, _WIN32_WINDOWS, _WIN32_IE or _MFC_VER depending on your feature. Or you can use newer SDK as indicated by Niklas. Or may be, you just need to define target platform or similar appropriately on top of stdafx.h.

#define _WIN32_WINDOWS 0x0600

It should be 1200 for VC6.

Sorry for my misunderstanding (read error) :laugh:. You mean touch pressure strength or, I think, sometimes called pressure size. I'm not sure that this is standard information beside location information reported by device. This theoretically possible feature may not be carried out by all manufacturers.

But, I couldn't find out how I could save it as default in my settings. Do you know how?