|
|
I did, but it doesn't work.
Don't try it, just do it! 
|
|
|
|
|
How about making all the UCHARs to USHORT?
John
|
|
|
|
|
Thank you John, that works!
Don't try it, just do it!
|
|
|
|
|
Yes, you are right. But how strange ... although I remembered that in C++ syntax, we only have to write this way for bit field:
struct SS
{
unsigned A : 13;
unsigned B : 1;
unsigned C : 1;
unsigned D : 1;
};
But with pragma of VisualC++7, the previous acts different to:
struct SS
{
unsigned short A : 13;
unsigned short B : 1;
unsigned short C : 1;
unsigned short D : 1;
};
Maxwell Chen
|
|
|
|
|
Hi
If you have problems with the size structue you have to close your structure declaration between #pragma pack() instruction, you can get additional info at msdn.
|
|
|
|
|
I want to insert the values i get from a matrix, in the order thay are in a text file. I mean by this the values to keep their place, on lines and columns.
To read the values I did this:
double LocalMap::SquareValue(int i, int j)
{
for (i=0; i<nx; i++){
="" for="" (j="0;" j<ny;="" j++){
="" if="" (cellv[i][j]="">0){
cellsV[i][j]=cellV[i][j]*cellV[i][j];
if (cellsV[i][j]>noise_border){
ofstream BuiltMap; //mode écriture
BuiltMap.open ("C:\\My Files\\BuiltMap\\BuiltMap.txt", ios::in);
//open file
while (!BuiltMap.eof()){
//laisser i colonnes libres et j espaces libres
BuiltMap<<"\n"<<" "<
|
|
|
|
|
for (i = 0; i < nx; i++)
{
for (j = 0; j < ny; j++)
{
if (cellV[i][j] > 0)
{
cellsV[i][j] = cellV[i][j] * cellV[i][j];
if (cellsV[i][j] > noise_border)
{
ofstream BuiltMap;
BuiltMap.open("C:\\My Files\\BuiltMap\\BuiltMap.txt", ios::in);
while (! BuiltMap.eof())
{
BuiltMap << "\n" << " " << cellsV[i][j];
}
}
else
cellsV[i][j] = NULL;
}
}
}Aside from the fact that the opening/closing of the file should be done outside of the loops, I'm not quite sure what you are doing here. You've got an ofstream object that is opening a file for input (i.e., reading), yet you are usign the << operator to write to it. Is this intentional?
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
I thought ifstream is made for reading files only, and ofstream to be able to write into file. Did I miss something there?
I want to write the values cellsV[i][j] into the BuiltMap file.
THX
|
|
|
|
|
So shouldn't you be opening the file with ios::out instead?
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
I am seeing an interesting problem using the SortChildrenCB
functionality in the CTreeCtrl class. When I add items to my
treectrl, I set the item data correctly with SetItem, along with some
other things, like the state, statemask. For my "private" item data I
am storing the HTREEITEM that I got back from the
CTreeCtrl::InsertItem call. I correctly cast it to an LPARAM from an
HTREEITEM.
The item gets added correctly and the SetItem also seems to work ok.
So, if I added two nodes to the tree the following values are used:
name1: "apples"
itemdata1: 713A8 (the HTREEITEM of the first node)
name2: "model"
itemdata2: 74008 (the HTREEITEM of the second node)
After adding each node, I fill the appropriate TVSORTCB structure as
follows:
tvs.hParent = parentH; // HTREEITEM of parent node
tvs.lpfnCompare = CompareItems; // address of my compare callback
routine
tvs.lParam = (LPARAM) &ctlTree; // pointer to my treectrl
ctlTree.SortChildrenCB(&tvs);
Now, when my callback routine gets called after adding the second item
to determine which way to sort the items, it gets called with the
itemdata of the first item, itemdata of the second item, and the "sort
parameter. I cast these accordingly:
CTreeCtrl* pMyTreeCtrl = (CTreeCtrl*) lParamSort;
// the lParam of an item is just it's handle
HTREEITEM hTreeItem1 = (HTREEITEM) lParam1;
HTREEITEM hTreeItem2 = (HTREEITEM) lParam2;
The problem is as follows:
the HTREEITEM of the first item gets munged -- by 2. So what I see
in the callback routine for HTREEITEMS is as follows:
hTreeItem1: 713AA (the HTREEITEM of the first node)
hTreeItem2: 74008 (the HTREEITEM of the second node)
Notice the difference in the value of the first handle. It should be
713A8, which is the correct node handle. This fouling up my sorting.
My question is this, to node handles persist? Do they live as long as
the tree node exists? Or, do they get reassigned during
expansion/contraction? In the past, I have hung pointers of more
complex "item data" on tree nodes without trouble. Of course I had to
be responsible for deallocating them when appropriate. But in this
case I thought I was safe using the HTREEITEM as item data, since
given that I could query the tree node for the sorting information I
needed.
Anyone have any ideas on this or have seen this behavior before?
Thanks in advance.
Roy Berger
roybrew@att.net
Regards,
Roy
_____________
Roy H. Berger
roybrew@att.net
|
|
|
|
|
An error occured when I use a function called "PESDEMUX_ProcessFile" which is defined in a Dll (XtlPes.dll) (I have no errors at compilation).
The error message I have is "Unhandled exception in Appli.exe (XTLPES.DLL): 0xC0000005:Access Violation."
The code I used is:
HINSTANCE g_hDllXtlPes; // Global Variable defined in the general class
g_hDllXtlPes = LoadLibrary("XtlPes.dll"); //
typedef LONG (__cdecl *PESDEMUX_ProcessFile)(CHAR*,CHAR*,INT);
PESDEMUX_ProcessFile pPESDEMUX_ProcessFile;
CHAR chInFileName[255];
strcpy(chInFileName, m_csPCFileName); //Conversion CString to CHAR*
CHAR chOutFileName[255];
m_csPCFileName = m_csPCFileName + ".mpg";
strcpy(chOutFileName, m_csPCFileName); //Conversion CString to CHAR*
INT Type = 1;
if (theApp.g_hDllXtlPes != NULL)
{
pPESDEMUX_ProcessFile = (PESDEMUX_ProcessFile)GetProcAddress(theApp.g_hDllXtlPes,"PESDEMUX_ProcessFile");
if (!pPESDEMUX_ProcessFile)
{
FreeLibrary(theApp.g_hDllXtlUsb);
return FALSE;
}
else
{
BOOL BResult = TRUE;
BResult = pPESDEMUX_ProcessFile(chInFileName,chOutFileName,Type);
}
}
Does someone have an idea ?
Thank's for advance.
|
|
|
|
|
use a debugger to determine what is going wrong!
Don't try it, just do it!
|
|
|
|
|
That's what I've done... But the function I use always returns FALSE...
Any ideas?
|
|
|
|
|
If LoadLibrary() fails, you shouldn't bother doing that other stuff.
HINSTANCE g_hDllXtlPes;
g_hDllXtlPes = LoadLibrary("XtlPes.dll");
if (NULL != g_hDllXtlPes)
{
typedef LONG (__cdecl *PESDEMUX_ProcessFile)(CHAR*,CHAR*,INT);
PESDEMUX_ProcessFile pPESDEMUX_ProcessFile;
CHAR chInFileName[255];
strcpy(chInFileName, m_csPCFileName);
CHAR chOutFileName[255];
m_csPCFileName = m_csPCFileName + ".mpg";
strcpy(chOutFileName, m_csPCFileName);
INT Type = 1;
pPESDEMUX_ProcessFile = (PESDEMUX_ProcessFile)GetProcAddress(theApp.g_hDllXtlPes,"PESDEMUX_ProcessFile");
if (NULL != pPESDEMUX_ProcessFile)
{
BOOL BResult;
BResult = pPESDEMUX_ProcessFile(chInFileName,chOutFileName,Type);
}
else
{
DWORD dwResult = GetLastError();
FreeLibrary(theApp.g_hDllXtlUsb);
return FALSE;
}
}
else
DWORD dwResult = GetLastError();Note the calls to GetLastError().
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
GetLastError() return 0.
Any ideas ?
|
|
|
|
|
So g_hDllXtlPes is NULL and GetLastError() returned 0. Is that right?
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
g_hDllXtlPes is not NULL but GetLastError() returned 0
|
|
|
|
|
Ok, so what's the problem? If g_hDllXtlPes is not NULL, I would expect GetLastError() to return 0. That means no error!
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
True but I have an error message "Unhandled exception in Appli.exe (XTLPES.DLL): 0xC0000005:Access Violation"...
And I haven't the result I would like to have which is the conversion of a file...
|
|
|
|
|
Set a breakpoint on the LoadLibrary() statement and step through each successive statement until the exception occurs. My guess is that you are calling the PESDEMUX_ProcessFile() function incorrectly or with invalid parameters.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Hi !
I'm using the std::vector class. Let's say my vector has 10 elements. I want to reach, with an iterator the fifth.
Here is what I'd like to do :
std::vector::iterator MyIt=MyVector.begin();
MyIt=MyIt+5;
MyResult=(*MyIt);
But it doesn't work. The only way I could make it work is to have a loop which will do five time ++MyIt !
Why can't I just to MyIt=MyIt+5 ? Any suggestions ?
Thanks !
Jerome
|
|
|
|
|
std::vector has random access iterators so you should be able to to do MYIt = MyIt + 5;
If you dont want to use a loop, you can use advance, which works for both random access and forward/reverse iterators.
#include < vector >
#include < iostream >
#include < algorithm >
using namespace std;
int main(int argc, char* argv[])
{
vector< int > v;
for (int i = 0;i<10;++i)
v.push_back(i);
vector< int >::iterator it = v.begin();
it = it + 5;
cout << *it << endl;
advance(it, 2);
cout << *it << endl;
return 0;
}
---
“Our solar system is Jupiter and a bunch of junk” - Charley Lineweaver 2002
|
|
|
|
|
It works here ...
vector<int> MyVector;
for(int i = 0; i < 10; i++)
MyVector.push_back(i +1);
std::vector<int>::iterator MyIt = MyVector.begin();
MyIt=MyIt+5;
int MyResult = (*MyIt);
cout << MyResult << endl;
MyIt = MyIt + 3;
MyResult = (*MyIt);
cout << MyResult << endl;
Result screen:
6
9
<b>Maxwell Chen</b>
|
|
|
|
|
Looks like it might just be a syntax error. Try changing
std::vector::iterator MyIt=MyVector.begin(); to
std::vector‹int›::iterator MyIt=MyVector.begin();
Notice the ‹int› after vector. Wow I never realized how much of a pain it was to put angle brackets in.
- Aaron
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
