cancel
Showing results for 
Search instead for 
Did you mean: 
EN
cancel
Showing results for 
Search instead for 
Did you mean: 
TomWaltz
Participant

IO Error question

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

Didn't find the answer?

Check other topics in this Forum

Back to Forum

Read the latest accepted solutions!

Accepted Solutions

Start a new conversation!