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.
How do you obtain the file name from Windows? Which API function call are you using? If the documentation for that API function call specifies that the name is null terminated, then you should not be getting the garbage. But some old file systems set off a fixed length buffer for the file name - even in Unix! The original Unix directory was 16 bytes per entry: two bytes inode, 14 chars filename. The orginal FAT had room for 8 char file name, 3 char extension. If the field was filled with a maximum length file name (in either Unix or FAT), there was no room for a terminating nul. If you reach the end of the field before finding a null, it is nevertheless the end of the field!
Remember that nul terminated strings is an idea conceived for the C language. It directoy conflicts with the ISO character set standard, whether ISO 646, 8859 or other variants. Other languages have used other solutions, e.g. in Pascal, a string is (at least in most implementations) represented by a length field associated with the string buffer (so the ISO NUL character can be used in the ISO standard way!). Many other languages to the same.
DOS was developed before C and Unix. Windows was developed before Unix had become very important, at least in the market segments Windows was aimed at. So you should not take for granted that all sorts of C / Unix conventions have been adopeted in every other segment.
You are making a wrong assumption. The sizeof(dir_struct->directory) operator will return 2048. But what if the string in that table is less than that? You need an actual count of the number of valid characters in the directory field (assuming that it is correctly null terminated).
You are also mixing the dot (.) and arrow (->) operators on your struct reference.
But all this is largely irrelevant. You need to go back a stage to the code that fills the directory structure in the first place, as that is where the problem is most likely to be found.
Last Visit: 28-Nov-20 9:19 Last Update: 28-Nov-20 9:19