I have a working Visual Studio project.
I've created a static library with the files of the original project (except main.cpp), also
I've created a "tester" project (with the static lib linked to it) with only a main.cpp file from the original project.
Both compiles without any relevant error.
And tester runs appropriately.
But! At testing the "tester" I am getting a heap allocation error at a (not the first)
new[] operator invoked in a constructor implemented in the library.
That line working fine in the original project without any error.
The "little" version of the code:
//the staticlib
void test() {
manager* m = new manager;
m->open();
}
//....
class manager {
public:
open() {
PRAWINPUTDEVICELIST lDevList;
UINT lDevCount;
GetRawInputDeviceList(NULL, &lDevCount, sizeof(RAWINPUTDEVICELIST));
lDevList = (PRAWINPUTDEVICELIST) malloc(sizeof(RAWINPUTDEVICELIST)*lDevCount);
GetRawInputDeviceList(lDevList, &lDevCount, sizeof(RAWINPUTDEVICELIST));
if(lDevCount) {
for(UINT i = 0; i < lDevCount; i++) {
HIDP_CAPS mCaps;
PHIDP_BUTTON_CAPS mButtonCaps;
PHIDP_VALUE_CAPS mValueCaps;
UINT size;
GetRawInputDeviceInfo(lDevList[i].hDevice, RIDI_DEVICENAME, NULL, &size);
char* name = new char[size+1];
//just to be sure
memset(name, 0, size+1);
//surely sure
name[size] = '\0';
GetRawInputDeviceInfo(lDevList[i].hDevice, RIDI_DEVICENAME, name, &size);
HANDLE lDev = CreateFile((LPCWSTR)name, 0, FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL, OPEN_EXISTING, 0, NULL);;
PHIDP_PREPARSED_DATA lPrep;
HidD_GetPreparsedData(lDev, &lPrep);
HidP_GetCaps(lPrep, &mCaps);
if(mCaps.NumberInputButtonCaps) {
//crash is here below
//mCaps.NumberInputButtonCaps ~1
mButtonCaps = new HIDP_BUTTON_CAPS[mCaps.NumberInputButtonCaps];
HidP_GetButtonCaps(HidP_Input, mButtonCaps, &mCaps.NumberInputButtonCaps, lPrep);
}
if(mCaps.NumberInputValueCaps) {
//if the first "crash-line" is commented, then
//the crash is here
mValueCaps = new HIDP_VALUE_CAPS[mCaps.NumberInputValueCaps];
HidP_GetValueCaps(HidP_Input, mValueCaps, &mCaps.NumberInputValueCaps, lPrep);
}
CloseHandle(lDev);
}
}
}
};
//the app
test();
Where I am wrong? Is it a typical novice commission I am not afraid of?
Sorry for my English, and thanks ahead for your time!
The error is that you should be allocating wide chars when you call GetRawInputDeviceInfo. From the manual
RIDI_DEVICENAME 0x20000007
pData points to a string that contains the device name.
For this uiCommand only, the value in pcbSize is the character count
(not the byte count).
In other words you should write
wchar_t* name = new wchar_t[size];
GetRawInputDeviceInfo(lDevList[i].hDevice, RIDI_DEVICENAME, name, &size);
Just from reading the manual, I have no actual experience with this API, but it seems a likely explanation.
Add logic that checks for error return states on every Win32 call you make. Possibly one of them is failing and when you remedy that, the rest will work. Always check for and handle errors when you are using Win32 APIs.
Related
I have folder of different documents like: pdf, txt, rtf, images.
My case is to send all documents to the printer (print it). Used framework is MFC and WinAPI. Current implementation has dialog box for choose documents and another dialog for choose printer.
Then question appears, how to print it all? Do I need to convert every documents to PDF, then merge it and print one pdf document? I will appreciate any advice in that field.
void CMultipleDocsPrintTestDlg::OnBnClickedButton1()
{
TCHAR strFilter[] = { _T("Rule Profile (*.pdf)||") };
// Create buffer for file names.
const DWORD numberOfFileNames = 100;
const DWORD fileNameMaxLength = MAX_PATH + 1;
const DWORD bufferSize = (numberOfFileNames * fileNameMaxLength) + 1;
CFileDialog fileDlg(TRUE, _T("pdf"), NULL, OFN_ALLOWMULTISELECT, strFilter);
TCHAR* filenamesBuffer = new TCHAR[bufferSize];
// Initialize beginning and end of buffer.
filenamesBuffer[0] = NULL;
filenamesBuffer[bufferSize - 1] = NULL;
// Attach buffer to OPENFILENAME member.
fileDlg.GetOFN().lpstrFile = filenamesBuffer;
fileDlg.GetOFN().nMaxFile = bufferSize;
// Create array for file names.
CString fileNameArray[numberOfFileNames];
if (fileDlg.DoModal() == IDOK)
{
// Retrieve file name(s).
POSITION fileNamesPosition = fileDlg.GetStartPosition();
int iCtr = 0;
while (fileNamesPosition != NULL)
{
fileNameArray[iCtr++] = fileDlg.GetNextPathName(fileNamesPosition);
}
}
// Release file names buffer.
delete[] filenamesBuffer;
CPrintDialog dlg(FALSE);
dlg.m_pd.Flags |= PD_PRINTSETUP;
CString printerName;
if (dlg.DoModal() == IDOK)
{
printerName = dlg.GetDeviceName();
}
// What next ???
}
You could make use of ShellExecute to do this. The parameter lpOperation can be set to print. To quote:
Prints the file specified by lpFile. If lpFile is not a document file, the function fails.
As mentioned in a similar discussion here on StackOverflow (ShellExecute, "Print") you should keep in mind:
You need to make sure that the machine's associations are configured to handle the print verb.
You referred to pdf, txt, rtf, images which should all be supported I would think by this mechanism.
ShellExecute(NULL, "print", fileNameArray[0], nullptr, nullptr, SW_SHOWNORMAL);
The last parameter might have to be changed (SW_SHOWNORMAL). This code would be put in a loop so you could call it for each file. And note that the above code snippet has not been tested.
I have read a few questions and topics on this issue. For example:
Warning message regarding stack size
But I can't really work out how I am to isolate the issue in the method:
void CCreateReportDlg::ReadOptions()
{
CHeadingsDlg dlgHeadings(this);
COptionsDlg dlgOptions(this);
CBrothersDlg dlgBrothers(this, FALSE);
CAutoAssignSettingsDlg dlgAssign(this);
CString strSection = theApp.GetActiveScheduleSection(_T("Options"));
// headings
m_strReportTitle = dlgHeadings.GetReportTitle();
dlgHeadings.GetHeadings(m_aryStrHeading);
m_eReportMode = dlgOptions.GetReportMode();
// brother data
dlgBrothers.GetBrotherData(SOUND, m_aryStrSoundWT, m_aryStrSoundSM, TRUE);
dlgBrothers.GetBrotherData(PLATFORM, m_aryStrPlatformWT, m_aryStrPlatformSM, TRUE);
dlgBrothers.GetBrotherData(MIKE, m_aryStrMikeWT, m_aryStrMikeSM, TRUE);
dlgBrothers.GetBrotherData(ATTENDANT, m_aryStrAttendWT, m_aryStrAttendSM, TRUE);
dlgBrothers.GetBrotherData(SOUND, m_aryStrBroSoundAll, TRUE);
dlgBrothers.GetBrotherData(PLATFORM, m_aryStrBroPlatformAll, TRUE);
dlgBrothers.GetBrotherData(MIKE, m_aryStrBroMikeAll, TRUE);
dlgBrothers.GetBrotherData(ATTENDANT, m_aryStrBroAttendAll, TRUE);
CCustomAssignManagerDlg::GetCustomAssignData(m_aryPtrAssign, TRUE, ASSIGN_SORT_HEADING);
if(m_eReportMode != MODE_MEETING)
{
// We need to update the arrays to only include the brothers that are available
// on both days (so the two arrays become identical)
ModifyBrotherArrays();
}
dlgBrothers.GetBrotherData(m_cbBrother);
// We need an array of unique names
// (without first to entries in combo)
// Used during printing and exporting (multi highlight)
dlgBrothers.GetBrotherData(m_aryStrNames);
CBrothersDlg::SortArray(m_aryStrNames);
// options
m_bExcludePlatformColumn = dlgOptions.ExcludePlatformColumn();
m_bExcludePlatformMikeColumn = dlgOptions.ExcludePlatformMikeColumn();
m_bExcludeAttendColumn = dlgOptions.ExcludeAttendantColumn();
m_iNumMikeUsers = dlgOptions.GetNumMikeUsers();
m_iNumSoundUsers = dlgOptions.GetNumSoundUsers();
m_iNumAttendUsers = dlgOptions.GetNumAttendants();
dlgOptions.GetMeetingDays(m_iDayWT, m_iDaySM, m_iDayWeek);
m_iDayWT++;
m_iDaySM++;
m_iDayWeek++;
dlgOptions.GetCustomDateOptions(m_bCustomDate, m_strDateFormat);
m_bAvoidBack2Back = dlgAssign.AvoidBack2Back();
m_bCheckForConflicts = dlgAssign.CheckForConflicts();
m_bSelectNames = dlgAssign.SelectNames();
theApp.ReadDateMapData(m_mapSPtrBroDates);
m_bShowNotes = (BOOL)theApp.GetNumberSetting(strSection, _T("ShowNotes"), (int)TRUE);
m_bNoticeBoard = (BOOL)theApp.GetNumberSetting(strSection, _T("NoticeBoard"), (int)FALSE);
dlgOptions.ReadAssignStatesInfoEx(m_byAryAutoAssignStates);
}
I know I can adjust the compiler and increase the stacksize to supress the error.
But what is the basic approach to identifying the route cause in my method?
The first bunch of variables are CStringArray. Then it is followed by a CPtrArray of objects, of type CUSTOM_ASSIGN_S:
typedef struct tagCustomAssignment
{
int iIndex;
CString strDescription;
CString strHeading;
BOOL bExcluded;
CStringArray aryStrBrothersAll;
CStringArray aryStrBrothersWT;
CStringArray aryStrBrothersSM;
BOOL bIncludeWT;
BOOL bIncludeTMS;
BOOL bFixed;
int iFixedType;
} CUSTOM_ASSIGN_S;
Again, none of the members of the above structure are large arrays [xxx]. The only other notable method is ReadDateMapData that reads an archive and fills another map.
But as mentioned, I don't know how to go about isolating the issue. There are no large arrays being define. One or two TCHAR file[_MAXPATH]; but that is about it. The rest of classes like CStringArray or CPtrArray etc..
Thank you in advance.
Update
Based on the comments provided I was able to establish that even just the variable declarations at the top:
CHeadingsDlg dlgHeadings(this);
COptionsDlg dlgOptions(this);
CBrothersDlg dlgBrothers(this, FALSE);
CAutoAssignSettingsDlg dlgAssign(this);
CString strSection = theApp.GetActiveScheduleSection(_T("Options"));
Would cause it to have a stack size of 18072 to begin with.
My main variables in this class were actually dialog objects which understandably are quite large due to all the member variables etc..
The reason I was using these dialogues was to gain access to application settings by using their public methods.
By changing these dialogue declarations to new / delete and adjusting the code I no longer get the stack size warning:
void CCreateReportDlg::ReadOptions()
{
CHeadingsDlg *pDlgHeadings = new CHeadingsDlg(this);
if (pDlgHeadings != NULL)
{
m_strReportTitle = pDlgHeadings->GetReportTitle();
pDlgHeadings->GetHeadings(m_aryStrHeading);
delete pDlgHeadings;
}
COptionsDlg *pDlgOptions = new COptionsDlg(this);
if (pDlgOptions != NULL)
{
m_eReportMode = pDlgOptions->GetReportMode();
m_bExcludePlatformColumn = pDlgOptions->ExcludePlatformColumn();
m_bExcludePlatformMikeColumn = pDlgOptions->ExcludePlatformMikeColumn();
m_bExcludeAttendColumn = pDlgOptions->ExcludeAttendantColumn();
m_iNumMikeUsers = pDlgOptions->GetNumMikeUsers();
m_iNumSoundUsers = pDlgOptions->GetNumSoundUsers();
m_iNumAttendUsers = pDlgOptions->GetNumAttendants();
pDlgOptions->ReadAssignStatesInfoEx(m_byAryAutoAssignStates);
pDlgOptions->GetCustomDateOptions(m_bCustomDate, m_strDateFormat);
pDlgOptions->GetMeetingDays(m_iDayWT, m_iDaySM, m_iDayWeek);
m_iDayWT++;
m_iDaySM++;
m_iDayWeek++;
delete pDlgOptions;
}
CBrothersDlg *pDlgBrothers = new CBrothersDlg(this, FALSE);
if (pDlgBrothers != NULL)
{
pDlgBrothers->GetBrotherData(SOUND, m_aryStrSoundWT, m_aryStrSoundSM, TRUE);
pDlgBrothers->GetBrotherData(PLATFORM, m_aryStrPlatformWT, m_aryStrPlatformSM, TRUE);
pDlgBrothers->GetBrotherData(MIKE, m_aryStrMikeWT, m_aryStrMikeSM, TRUE);
pDlgBrothers->GetBrotherData(ATTENDANT, m_aryStrAttendWT, m_aryStrAttendSM, TRUE);
pDlgBrothers->GetBrotherData(SOUND, m_aryStrBroSoundAll, TRUE);
pDlgBrothers->GetBrotherData(PLATFORM, m_aryStrBroPlatformAll, TRUE);
pDlgBrothers->GetBrotherData(MIKE, m_aryStrBroMikeAll, TRUE);
pDlgBrothers->GetBrotherData(ATTENDANT, m_aryStrBroAttendAll, TRUE);
pDlgBrothers->GetBrotherData(m_cbBrother);
// We need an array of unique names (without first two entries in combo)
// Used during printing and exporting (multi highlight)
pDlgBrothers->GetBrotherData(m_aryStrNames);
CBrothersDlg::SortArray(m_aryStrNames);
delete pDlgBrothers;
}
CAutoAssignSettingsDlg *pDlgAssign = new CAutoAssignSettingsDlg(this);
if (pDlgAssign != NULL)
{
m_bAvoidBack2Back = pDlgAssign->AvoidBack2Back();
m_bCheckForConflicts = pDlgAssign->CheckForConflicts();
m_bSelectNames = pDlgAssign->SelectNames();
delete pDlgAssign;
}
CCustomAssignManagerDlg::GetCustomAssignData(m_aryPtrAssign, TRUE, ASSIGN_SORT_HEADING);
if(m_eReportMode != MODE_MEETING)
{
// We need to update the arrays to only include the brothers that are available
// on both days (so the two arrays become identical)
ModifyBrotherArrays();
}
theApp.ReadDateMapData(m_mapSPtrBroDates);
CString strSection = theApp.GetActiveScheduleSection(_T("Options"));
m_bShowNotes = (BOOL)theApp.GetNumberSetting(strSection, _T("ShowNotes"), (int)TRUE);
m_bNoticeBoard = (BOOL)theApp.GetNumberSetting(strSection, _T("NoticeBoard"), (int)FALSE);
}
i am currently trying to figure out a way to write a file (an allegro configuration file to be exact) to a mounted zip-file using physfs and allegro 5.
reading the config file works fine, but when it comes to writing the changed config, nothing happens (e.g. the file is not re-written and thus remains in it's old state).
also, when not using physfs, everything works perfectly.
here's the code i use:
Game::Game(int height, int width, int newDifficulty)
{
PHYSFS_init(NULL);
if (!PHYSFS_addToSearchPath("Data.zip", 1)) {
// error handling
}
al_set_physfs_file_interface();
cfg = al_load_config_file("cfg.cfg");
if (cfg != NULL) // file exists, read from it
{
const char *score = al_get_config_value(cfg, "", "highScore");
highScore = atoi(score); // copy value
}
else // file does not exist, create it and init highScore to 0
{
cfg = al_create_config();
al_set_config_value(cfg, "", "highScore", "0");
highScore = 0;
al_save_config_file("cfg.cfg", cfg);
}
...
}
and in another function:
void Game::resetGame()
{
// high score
if (player->getScore() > highScore)
{
highScore = player->getScore();
// convert new highScore to char* that can be saved
stringstream strs;
strs << highScore;
string temp_str = strs.str();
char const* pchar = temp_str.c_str();
if (cfg != NULL) // file exists, read from it
{
al_set_config_value(cfg, "", "highScore", pchar);
al_save_config_file("cfg.cfg", cfg);
}
}
...
}
since the code works without physfs, i guess i handle the config file itself correctly.
any help would be highly appreciated!
cheers,
hannes
in the meantime, i solved the issue myself.
apparently, physfs has no ability to write to an archive.
therefore, i need to PHYSFS_setWriteDir("jhdsaf"), save the cfg-file in that folder and then replace the original zip-file by an updated version with the cfg-file, just before the game closes (after all resources are unloaded because the zip is otherwise still in use).
if anyone is interested in the code to do this, just reply to this post!
hannes
I am using CLucene for creating indexing and searching. The index files created are of more than 5 GB. I have Created the seperate dll for CLucene search.
DLL constructor contains the following code
lucene::index::IndexReader ptrIndexReader;
lucene::search::IndexSearcher searcher; these are defined in class decalaration/
ptrIndexReader = IndexReader::open(pDir.c_str(),false,NULL);
searcher = new IndexSearcher(ptrIndexReader);
I use one search function whose code is as follows
bool LuceneWrapper::SearchIndex(wstring somevalue)
{
lucene::analysis::KeywordAnalyzer fAnalyzer;
Document doc = NULL;
Hits hits = NULL;
Query f_objQuery = NULL;
NistRecord *f_objRecords = NULL;
bool flag = false;
try{
if (ptrIndexReader == NULL)
{
return NULL;
}
// Initialize IndexSearcher
wstring strQuery = _T("+somename:") + somevalue;
// Initialize Query Parser, with Keyword Analyzer
QueryParser *parser = new QueryParser( _T(""),&fAnalyzer);
// Parse Query string
f_objQuery = parser->parse(strQuery.c_str());
// Search Index directory
hits = searcher->search(f_objQuery);
//searcher.
int intHitCount = 0;
intHitCount = hits->length;
if(intHitCount > 0)
{
if(doc!=NULL)
delete [] doc;
flag = true;
}
//searcher.close();
}
catch(CLuceneError& objExp)
{
if(doc!=NULL)
delete doc;
return false;
}
if(hits!=NULL)
delete hits;
if(f_objQuery!=NULL)
delete f_objQuery;
return flag ;
}
I am searching very large number of values. according to the record count the main memory goes high and high and at on level it goes near to 2 GB and application crashes. Can anybody tell me what is wrong with this? Why is memory going so high and application crashing?
You never deallocate parser.
I can't see a reason to allocate it dynamically.
Why don't you just say
QueryParser parser( _T(""), &fAnalyzer);
f_objQuery = parser.parse(strQuery.c_str());
You also need to make sure that you delete both f_objQuery and hits in the event of an exception.
std::unique_ptr can help you here, if you have access to it.
(And you don't have to test for NULL so much - it's OK to delete a null pointer.)
I'm trying to implement some WIA 2.0 code in my VS2012 C++ library and have run into a problem with the IWiaDevMgr2::GetImageDlg call, specifically the ppbstrFilePaths paraneter. I'm not quite sure how to declare/initialize it.
From the documentation at http://msdn.microsoft.com/en-us/library/windows/desktop/aa359932(v=vs.85).aspx:
ppbstrFilePaths [in] TYPE - BSTR**
The address of a pointer to an array of paths for the scanned files. Initialize the pointer to point to an array of size zero (0) before IWiaDevMgr2::GetImageDlg is called. See Remarks.
I've tried all sorts of variations on declaring this with no success, for example:
// No scanner selection dialog, hr = E_OUTOFMEMORY
BSTR *files = new BSTR[0];
HRESULT hr = _pWiaDevMgr->GetImageDlg(0, NULL, *_parentHwnd, path, fileTemplate, numFiles, &files, &_pWiaItemRoot);
I've also tried things similar to this:
// No scanner selection dialog, hr = E_OUTOFMEMORY
BSTR **files = (BSTR**)CoTaskMemAlloc(0);
*files = new BSTR[0];
HRESULT hr = _pWiaDevMgr->GetImageDlg(0, NULL, *_parentHwnd, path, fileTemplate, &numFiles, files, &_pWiaItemRoot);
Can anyone point me in the right direction for declaring and initializing this BSTR**? I'm not a big C++ dev and pretty much guessing at this point.
Turns out I was on the right track with my first try:
CComBSTR path("D:\\TestWiaScan");
CComBSTR fileTemplate("FileName");
LONG numFiles = 0L;
BSTR *files = new BSTR[0];
HRESULT hr1 = _pWiaDevMgr->GetImageDlg(0, NULL, _parentHwnd, path, fileTemplate, &numFiles, &files, &_pWiaItemRoot);
if (files)
{
for(int i=0;i < numFiles;i++)
{
SysFreeString(files[i]);
}
}
CoTaskMemFree(files);
if (_pWiaItemRoot)
{
_pWiaItemRoot->Release();
_pWiaItemRoot = NULL;
}
The reason my first try wasn't working was because of issues with the BSTR parameters I was passing in. Using CComBSTR or SysAllocString resolved that.