2024 Technology Preview Program:
Master powerful new features and shape the latest BIM-enabled innovations
2004-07-01
03:49 PM
- last edited on
2023-08-07
12:18 PM
by
Doreena Deng
#include "DG.h" // brings file selection dialog (and also includes Location) IO::Location loc; if (!DGGetOpenFile (&loc)) { // returns the selected location in loc // no file (folder, link) location was selected }but I just couldn't get it to work. I even searched through all the documentation without finding any other reference to DGGetOpenFile. So I gave it up.
IO::Location fileLoc; // Location instance IO::File file (fileLoc); char buffer[128]; DG::FileDialog dlg (DG::FileDialog::OpenMultiFile); if (!dlg.Invoke ()) return false; int count = dlg.GetSelectionCount (); for (int n = 0; n < count; n++) { IO::File file (dlg.GetSelectedFile (n)); errorCode = file.Open (IO::File::ReadMode); // opening the file in read-only mode errorCode = file.ReadBin(buffer, 128); DGAlert(DG_INFORMATION, "Inside while", buffer, 0, "OK", "Cancel", 0); }This lets me open my file from a filedialog. One problem though, is that I can't open it as myFile.sos, which is what it is, I have to rename it to myFile.txt. Why is that, and what can I do with it?
2004-07-05 01:56 PM
vannassen wrote:Hmm, yes I think DOSN8 is a 8 bit encoding. I was mistaken the strange output example:
I don't now what kind of encoding it has, but one of the first lines in the file says characterset DOSN8, which I'm guessing is some sort of DOS textfile with norwegian characters in it - in other words it should include Æ Ø Å, but I'm getting stuff like ù è when I view it in TextEdit here on my Mac.
My question then is what kind of math do I have to perform to be able to copy the just the first line into another charbuffer?It seem I am not quite well understoood your issue.
2004-07-05 03:47 PM
2004-07-05 11:23 PM
Tor wrote:Are you saying that after calling CHSearchSubstring, the return result in linePtr is 0? If so, it is indicating to you that the string was not found, i.e. it did not find a CR in the data buffer. You should certainly check for a null result anyway, because any to attempt to use the value would be invalid.
Then I'm searching for the first occurence of "\r" like thisGSPtr linePtr = CHSearchSubstring("\r", buff, fLength); // pointing to the first cr
Then I'm left with a ptr to the beginning of the text in buff and a ptr to the first cr in linePtr.
The length of buff is 22261 and the length of linePtr is 0, which is not quite what I wanted - but I guess it makes sense since it just points to the position of cr.
My question then is what kind of math do I have to perform to be able to copy the just the first line into another charbuffer?
CHSetDefaultCharCode(CC_WestEuropean);Perhaps we could speed this up if I could take a look at this file. Can it be downloaded from somewhere? Otherwise you could send it to the address on Encina's contact page.
2004-07-06 11:17 AM
Are you saying that after calling CHSearchSubstring, the return result in linePtr is 0?
BMGetPtrSize(linePtr)
2004-07-06 05:30 PM
Tor wrote:OK, I understand. This won't work because BMGetPtrSize will only tell you the size of a block of memory allocated as a Ptr, i.e. you can't ask it the size of an arbitrary address. A Ptr is not a string - it is an allocated block of memory which could contain anything.
When I write the linePtr to the alert window it shows whats left of the textfile starting from the position after the search string. But when I try to figure out how long this piece of information is by usingBMGetPtrSize(linePtr)
I get the result 0.
Tor wrote:Your assessment of the encoding type name sounds logical - hopefully it is an 8-bit encoding, because you can then use standard C/C++ string handling. BTW, a byte is an 8-bit value; a 32 bit value is often referred to as a long integer.
The second line in the file says ..TEGNSETT DOSN8, which means characterset MS-Dos Norwegian 8-bits. If I'm to speculate, I would guess the reason for getting the strange .??† result when trying to display the first character, which is a ., is that the character in it self only occupies the first 8 bits of the 32 bit byte.
Tor wrote:Got it - I'll let you now once I've had a chance to look into it.
I would be happy to send you the file - coming soon to a mailbox near you...![]()
2004-07-08 12:07 AM
Tor wrote:I took a look at the file, and it does indeed seem to be an 8-bit encoding. I was able to read and parse the file using the String Manager functions with the default character code set to 'CC_WestEuropean'. Use 'CHSetDefaultCharCode' to change the default if this is not your system default. Let me know if this improves the situation.
I would be happy to send you the file - coming soon to a mailbox near you...![]()