It is just the same as OpenFile behind the scenes so nothing to do with CFile. Your call probably fails because you are not including the share flags in your call to CFile::Open(), which are required when trying to access a device.
As others have pointed out, the issue is with pBuffer not associated with any allocated memory.
In addition to this, I would like to point out one more flaw in your code, although it doesn't matter in this case.
The third parameter to SetFilePointer[^] must be an address of a LONG variable. PLONG does not declare a LONG variable. It's only a pointer to a LONG variable.
Here SetFilePointer will actually try to write to memory 0.
What you need to do is declare a LONG variable and provide its address -
LONG highValue; SetFilePointer(..., ..., &highValue, ...);
You can also pass a nullptr, if you're not intersted in that value.
«_Superman_» I love work. It gives me something to do between weekends.
Microsoft MVP (Visual C++) (October 2009 - September 2013)
If you are referring to array cells with two dimension values then you should use a two-dimensional array. As it is you can pass any values in to NodeCoord but there is no way of telling if they are valid. So you could end up with lots of random memory corruption.
I think you could do with studying all the features of C (or C++ if that is what you are using). Trying to learn a language by posting questions here will take ten times as long, and you will still miss most of it.
Internally it's just continuous memory that is allocated for a 2 dimensional array (For any no. of dimensions for that matter).
The compiler uses the specified dimensions to calculate the offset into the memory to fetch.
For instance, offset of Chart could be calculated as -
I have a shipping piece of software, that uses property sheets for Tools/Options. For almost all my customers everything is perfect, but for just 2 or 3 the property sheets appear as though the dialog units are too large. The fonts, edit boxes, and all controls are about 1/3 too large, but with the same 0,0 origin. Even so, the containing dialog size is unchanged, so the result is that some of the controls on the right and bottom are either clipped or not visible at all.
We only use property sheets in two places, and for customers with this problem, both instances are affected identically. This only happens with Property sheets, and not with normal dialogs.
I have run your dialog and tried various changes to see if it affects it but nothing seems to go wrong. It may be worth checking the versions of Windows that the clients are running to see if that is a common factor.