Archicad C++ API
About Archicad add-on development using the C++ API.

IO Error question

TomWaltz
Participant
In the API documentation, there is a section on Input and Output. I have been looking at the sections on copying and deleting files, namely FileSystem::Copy.

It says there that most of the errors are "declared in FileSystem class scope."

(OK, this may be a C++ question, not an API question, I'm not sure).

As a result, all of my error checking statements, i.e.: if (err == SourceNotFound) return an error that "SourceNotFound" is an invalid identifier".

It seems that all the global scope error messages work. (no surprise).

I have file.hpp and filesystem.hpp included already, which I thought might be the problem.

I've tried fileSystem.SourceNotFound and fileSystem::SourceNotFound, with no luck.

How do I get a pre-defined error value from the FileSystem class scope to work in mine?
Tom Waltz
12 REPLIES 12
TomWaltz
Participant
This goes back to my desire to make my Archicad add-on self updating.

My idea was that when our next Archicad disk image is deployed, it would contain a copy of our in-house add-on.

Obviously, the add-on runs while Archicad is running. The idea is that whenever Archicad is quit, the Notification Manager tells the Add-on to look in a specified folder on the network. If there is an update there, it will copy the update, over-writing the Add-on currently on the local hard drive.

I have all the logic working inside the add-on. My problem is with the file operations, namely copying the file from the network location to the local folder.

Since IO::fileSystem.Copy cannot overwrite files, I had to add a routine to delete the file, then try again:
const char* networkFileLocation = "Public:CAD_Standards:KA-Update:KA-Add-On"; 
const char* localFileLocation = "Local_Disk:Applications:ArchiCAD 8.1 folder:Add-Ons:KA:KA-Add-On";
		
// define Location objects
IO::Location 	networkFile (networkFileLocation);
IO::Location 	localFile (localFileLocation);

GSErrCode 	err;    
GSErrCode	err2;	// temporary to help track down delete failure
err = IO::fileSystem.Copy (networkFile, localFile);
if (err == IO::Folder::SourceNotFound)
	{
		char    msgStr[256];
		CHCopyC ("Error, Source not found", msgStr);   
		ACAPI_WriteReport (msgStr, false); 
	}
else if (err == IO::Folder::TargetExists)
	{
		err2 = IO::fileSystem.Delete(localFile);
		if (err2) 
			{
				char    msgStr[256];
				CHCopyC ("Delete Failed", msgStr);   
				ACAPI_WriteReport (msgStr, false); 
				return;
			}
		IO::fileSystem.Copy(networkFile, localFile);

		char    msgStr[256];
		CHCopyC ("Updated from source", msgStr);   
		ACAPI_WriteReport (msgStr, false); 
	}
return;
I cannot figure out while I keep getting the "Delete failed" message, and the Delete function fails. I suspect that is may have to do with the mixture of fileSystem and Folder namespaces/object behavior.

At that point, I began to think about using an external shell script, called when Archicad is quit.

As I've said before, since updates of our inhouse add-on is a sporadic but unpredictable event, and a CAD issue, not really an IT one, we wanted to make it as self contained as possible, namely by making the add-on copy itself whenever needed.

Thanks!!
Tom Waltz
Andras Babos
Graphisoft Alumni
Graphisoft Alumni
"TomWaltz" wrote:

I cannot figure out while I keep getting the "Delete failed" message, and the Delete function fails. I suspect that is may have to do with the mixture of fileSystem and Folder namespaces/object behavior.


I'm afraid your problem is system- not ArchiCAD-related. You get a Delete Failed message because you are trying to delete a DLL (your Add-On) which is actually running. Your program is basically trying to delete itself!

What you can do is use a separate Add-On, which does nothing else just updates your original Add-On. Just make sure first that the original Add-On is already unloaded.

HTH:
Andras.
TomWaltz
Participant
What you can do is use a separate Add-On, which does nothing else just updates your original Add-On. Just make sure first that the original Add-On is already unloaded.
Wow, you read my mind.

That's exactly what I just now ended up doing. It makes sense that an executable cannot delete itself, but it sure was entertaining to try!!
Tom Waltz