BaseFile [SOLVED]

On 03/10/2014 at 20:18, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   R14 
Platform:   Windows  ;   
Language(s) :     C++  ;

---------
Hi Folks,
I'm trying to learn some basics of writing and reading to a file type. Nothing spectacular, but I need a small function to write some data to file that can be opened again later. The following is what I've been testing with:

  
Filename FN;  
FN.SetDirectory(GeGetPluginPath());  
FN.SetFile("Test File Save");  
FN.SetSuffix("txt");  
AutoAlloc< BaseFile > bf;  
//FN.FileSelect(FILESELECTTYPE_ANYTHING, FILESELECT_SAVE, "Save Your Work"); //Opens the file browser 
if(bf->Open(FN.GetFile(),FILEOPEN_WRITE,FILEDIALOG_ANY,BYTEORDER_INTEL,MACTYPE_CINEMA,MACCREATOR_CINEMA) == TRUE)  
{  
    MessageDialog("File opened succesfully..");  
    bf->WriteString("Test string");  
}
if(bf->Close() == TRUE)  
{  
    MessageDialog("File closed succesfully..");  
}  

Two queries follow:
 
First, the problem: if I uncomment the FN.Fileselect() line, I can see that there are previous saves of the file, but when I look in explorer etc, they're not visible. Doesn't matter if it's in the plugin folder, or on the desktop, they don't show. Why is this?
 
For the purpose of testing, I'm simply trying to save to the plugin's path, in a text file-like format. If it helps, one thing I did note is that when I use the 'save file dialog' I can see that the icons have a little lock on them (something of the sorts anyway) but when I right click to try open them from within the save file dialog, notepad says it can't find the file.
 
Second: is it possible to override the file icon with your own in the saved file (whether with Cinema or standard routines)?
 
Cheers,
 
WP.
 
P.s. I might just mention too, ignore the bf.WriteString() as I think for a text file it might need to be a series of chars (is this correct?). For the moment though, unless that itself causes a problem, I just want to be able to see the file, to save and load it within Cinema - that's all it will need.

On 04/10/2014 at 23:24, xxxxxxxx wrote:

First, the problem: if I uncomment the FN.Fileselect() line, ... Why is this?

I just tried your code here in R15 under Windows. And as far as I can see, it works as expected (even with uncommented FileSelect()). It creates the file, writes the string. And on the next call, I can also see the created file in the FileSelect-Requester.

Are you sure, C4D has access rights to the plugin folder? The "little lock" you mention later on, makes me think, you might not (although you mention desktop as target folder, can you lease double check). There's GeGetStartupWritePath() to get a writable path. Just in case you missed that one.

If I'm wrong with my assumption, can you please try to elaborate a little more, so I can reproduce it a little better. Or perhaps I misunderstood the problem and did the wrong test...

Second: is it possible to override the file icon...

I'm not sure I understand this correctly. The file icon is created/shown by the system for certain filetypes. So it depends on the default application registered for a certain filetype, which icon gets shown. There are exceptions, e.g. under windows, executables can have embedded icons. But I don't think, that's what you are talking about.

bf.WriteString() as I think for a text file it might need to be a series of chars (is this correct?)

You are right with the WriteString() assumption. All these Write...() functions store extra information to the file (if I'm not completely mistaken). You'd need to use Read/WriteBytes() and yes, you'd need to pay attention to GeGetByteOrder(). Which on the other hand is not that hard. I'm currently searching the SDK for swap macros, which do this for you. I'm pretty sure there have to be some somewhere, but I'm still finding my ways through the SDK and code, so this may take a while. I'll make a note and will add the info here, as soon a have come across.

On 05/10/2014 at 19:49, xxxxxxxx wrote:

Hi Andreas,
 
just to clarify the save folder - I've been test saving to the plugin folder via GeGetPluginPath(). I've also tried a couple of test saves to a folder I've got on the desktop just to see if the location made any difference. In both cases, the same thing happens (*see p.s. below). Hope that's a bit clearer. That said, I've just tried running Cinema with administrative rights, and I can now see a file in the folder on the desktop, but still not in the plugin folder. Is it possible to save without the need to have administrative rights? Or is there a flag I can use to warn the user that the file might not save to OS-related folders because Cinema is not running with administrative rights?
 
The second one regarding the file icon - you are on to it - is it possible to embed icons into file types? Or, can I 'install' (somehow) with my plugin, an icon so that the file type is recognised?
 
Cheers,
 
WP.
 
P.s. Just for notes' sake, I'm currently working remotely on a laptop, which only has the one drive.

On 05/10/2014 at 21:59, xxxxxxxx wrote:

Sorry, I tricked myself yesterday... I think the actual problem with your code is here:

if(bf->Open(FN.GetFile(),FILEOPEN_WRITE,FILEDIALOG_ANY,BYTEORDER_INTEL,MACTYPE_CINEMA,MACCREATOR_CINEMA) == TRUE)

You are only using the "file" part of the filename (which confused me yesterday, as using no path lead to the same result as using GeGetPluginPath()).
Please try passing FN instead of FN.GetFile() like this:

if(bf->Open(FN,FILEOPEN_WRITE,FILEDIALOG_ANY,BYTEORDER_INTEL,MACTYPE_CINEMA,MACCREATOR_CINEMA) == TRUE)

I think, then you'll get error codes as expected, if the file couldn't be opened for writing.

Regarding the icon question, have a look here:
http://msdn.microsoft.com/en-us/library/windows/desktop/hh127427(v=vs.85).aspx
or here:
http://www.sevenforums.com/tutorials/57455-file-extension-icon-change-default-icon.html
Please note, this is actually beyond SDK support, and neither me nor MAXON may be held responsible, if the guidelines on these sites do any harm to your system.

On 06/10/2014 at 06:57, xxxxxxxx wrote:

Re the icons, that's no troubles, I don't expect anyone to be responsible for my ventures into the wilderness! But the links are handy - I prefer to get that kind of thing from here where the users/support are more likely to point you in the right direction with Cinema plugin programming in mind. Not sure what to make of the icon step itself though, it's really just a 'do more than is expected' kind of thing, that's all. Will have a think on that one.
Back to the main one, I've just tried removing the GetFile() from that argument, but I don't get any error thrown and bf->Open() still returns true. I'll need to pick this up again in the morning, but strangely enough I also just ran a test trying to load the files from within Cinema where they can be seen in a 'load file' dialog, and it read the values back correctly!
 
Should not having administrative rights throw an error here if the path is in the plugin folder?
 
WP.

On 06/10/2014 at 07:04, xxxxxxxx wrote:

I double checked this here and I do get an error, if I don't have write access to the specified folder/file.
Seems pretty strange. Do you have any security software installed, like a sandbox or so? Such could abstract the write access and redirect it to RAM.
I personally used these functions in one of plugins before and i have never had such an issue.
Which version of C4D are you experimenting with?

On 07/10/2014 at 01:48, xxxxxxxx wrote:

No security software here, just standard Windows firewall etc. I've just done the updates to R14.042, but still shows the same behaviour. Testing on 32bit. Seems a bit strange Explorer won't recognise the files outside of Cinema - maybe it's the laptop/Windows? Unfortunately this is all I've got to work on for the next 2 or so months as I'm away.
 
WP.

On 07/10/2014 at 02:00, xxxxxxxx wrote:

I'm sorry the problem persists.
One thought I came across over night... a weak one though. On Win7 there a loads of directories, which are abstracted in one way or the other. Some are called differently for the user as in the filesystem for localization reasons. Some are named differently internally for compatibility reasons. For example on a Win7 64-Bit even some file management tools as Total Commander in the beginning had problems showing some system directories in the correct way. So maybe the explorer is playing tricks on you?

Unfortunately I'm not sure, what I can do to help any further.
Perhaps you can send me your project with a note, what you expect to exactly happen. And I'll give it a quick shot here. The project will need to compile flawlessly though, as my time is limited and I won't be able to debug into it anymore than needed to solve this issue. Leave me a PM, if you'd like to accept this offer.

On 07/10/2014 at 02:46, xxxxxxxx wrote:

At first when i read this i thought it could be a DiskLevel thing - did you ever attempt this using Hyperfile and maybe NodeData::Read() which accepts a disklevel parameter?

To be honest i was surprised that my plugin was able to write hyperfiles to the plugins folder without complaint, as windows asks me for permission if say i try to copy/paste and icon.tif into it.  But it saves the hfs no problem.  Im guessing C4D has permissions, but i`m constantly annoyed with Windows (7 64bit) forcing me to give permission for VisualStudio and C++ etc to open with admin rights..

I haven`t tried BaseFile before so no idea if the permissions thing differs between BaseFile and HyperFile.  Not even sure what the point of basefile is tbh..

On 07/10/2014 at 03:06, xxxxxxxx wrote:

Small side note: Beginning with the R16 SDK you can move your projects around freely. So this cumbersome working in the plugins folder has an end.

On 08/10/2014 at 06:59, xxxxxxxx wrote:

Hi folks,
 
I've had a go with hyperfiles - and the same thing happens. A little frustrated I can't test this on my work machine, then I might be able to rule in/out os/computer specific causes.
 
Bare with me for a couple of days - I'm going to re-write one of the dialog's layouts. Not directly because of this issue - it needed a make-over anyway. But the newer layout will be nicer to look at and work with than what it is at the moment.
 
I'll need to strip a few things out to minimise build times Andreas. I'll try drop back in sometime at the end of the week, or over the weekend, if a fix doesn't come to light beforehand. There's no rush on this particular plugin, but the saving of files etc is something I need for others as well, so seeing it work in this one will make me a bit more confident when applying it to the others. Cheers,
 
WP.

On 08/10/2014 at 12:00, xxxxxxxx wrote:

I use both BaseFile and HyperFile at different occasions to store data. Both work fine on PC and MAC so the assumption that there is something going wrong with permissions would also be my guess (from the sound of them not being visible..having a lock sign as you mentioned).

Eclectrik: Well a hyperfile can be associated with a basedocument for example and used to only be for read/write operations for plugin data in the past (which changed). That's why it can also write more specific data to the file.

BaseFile however is more of a usual file character where you can set properties like Byte order etc. specifically. It may be more useful for custom data file formats.

On 08/10/2014 at 15:00, xxxxxxxx wrote:

Thanks Katachi that`s useful to know..

On 16/10/2014 at 07:01, xxxxxxxx wrote:

Don't know if this is a silly question or not... but can we attach files to PMs (or any message for that matter)? It's no troubles if we can't, I just can't seem to find anything that will do that in the message options if we can.
 
WP.

On 21/10/2014 at 05:36, xxxxxxxx wrote:

Hi All,
 
just letting other readers know that the above issue did appear to be permissions-related. With them turned off, I can now see that BaseFiles are written to the plugins folder, and are seen in Explorer like any other normal file.
 
WP.

On 21/10/2014 at 05:40, xxxxxxxx wrote:

Glad you got it working on your end. :slightly_smiling_face: