IO Error question

Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ā2004-05-15
12:33 AM
- last edited on
ā2022-12-13
09:56 PM
by
Daniel Kassai
ā2004-05-15
12:33 AM
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?
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
Labels:
- Labels:
-
Add-On (C++)
12 REPLIES 12

Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ā2004-05-17 06:47 PM
ā2004-05-17
06:47 PM
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:
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!!
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

Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ā2004-05-20 04:28 PM
ā2004-05-20
04:28 PM
"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.

Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ā2004-05-20 04:57 PM
ā2004-05-20
04:57 PM
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
- Ā« Previous
-
- 1
- 2
- Next Ā»
- Ā« Previous
-
- 1
- 2
- Next Ā»