Goal: excel macro that creates a new lotus notes email subfolder
I am totally new when it comes to VBA and Lotus Notes in general.
I would appreciate if smb would indicate some directions in achieving my goal, because until know I wasn't able to find anything similar.
1) how do I connect to needed mail (regarding this I saw some info, but a clear code example would be great)
2) how do I create the subfolder with a specified name and indicate the folder where it should be created
There is no API for a folder architechture because there really is no folder architecture. Nested folders are an illusion just based on the name of the folder. I.e., the folder name "folder1\folder2" indicates that folder2 appears to be inside folder1, but the structure is flat as far as all APIs are concerned.
The NotesDatabase.EnableFolder() method will create a folder. (It's a dumb name for the method!) Existing folders can be accessed via NotesDatabase.GetView() method because from the high-level API point of view Folder and Views are treated as equals. The NotesView.Remove() method can be used to delete a folder. The NotesView.Name property is read/write.
Related
I wanna try OneDrive Api for Android and I was taking a look at the methods and possibilities this Api offers on this link and this other one but I don't see any way of listing the files a folder contains.
My App would need to upload some files to OneDrive, always using the same folder as root, say /MyFolder. The problem is that it only knows this root folder and all its content must be found out by means of recursive calls, that is, I list the files contained in /MyFolder and check if it's a folder or a file and in the first case list the files again it contains and so on.
Am I missing something or this Api doesn't provide such thing?
The Json object returned for a query against a Folder should contain a "data" property that is an array of children for the folder. You can see this in the interactive SDK (http://isdk.dev.live.com/dev/isdk/default.aspx) by playing with the "Reading Folder Properties" API.
I'm trying to work with the new summer release of the Office 365 API tool for Visual Studio 2013 (update 3). It works fine except one problem I've encountered which can be called also a missing functionality.
I found no reasonable way to retrieve the direct children of the root folder from my One Drive for business Document Library using the newly added SharePointClient library.
The API call of SharePointClient.Files will retrieve all the files and folders from the whole document library including sub-folders. So in order to get only the direct children I have to page through all the documents and folders and analyze their URL. This is not acceptable for my application scenario. For a sub-folder I can get the direct children like this: SharePointClient.Files["<folder_id>"].ToFolder().Children This is what I need but it can't be applied to the root folder.
I've tried to use the REST API directly and similarly the request GET ../_api/files will retrieve all files and folders in the default document library and I found no simple way to list only the direct children of the root. Also there is no convenient way to get the path or GUID of the default document library which the SharePointClient.Files automatically uses.
Parsing the result XMLs of the REST API calls I may get the GUID of the default document library, that will let me use a different REST API to list files and folders separately for the root folder, but these calls results in a different XML schema from that used by SharePointClient. This means that to get only the direct children of the root I would have to re-implement the whole SharePointClient library.
If anybody has some good advice I'll be very thankful.
I just ran into the same issue - hopefully this will be remedied before the release version of the api tools. Here is what I've done to get only the root folder content:
[Create your spClient = SharePointClient]
var allFiles = await spClient.Files.ExecuteAsync();
var rootFiles = allFiles.CurrentPage.Where(i => !i.Id.Contains("/"));
You lose the IPagedCollection wrapper and you may need to get more than the 'CurrentPage' to see all files but this is the best workaround I've found. I'm then able to you the 'ToFolder()' method you mentioned above to list content of sub-folders.
I am exporting all the e-mails from folder and sub-folder of exchange server, i am able to get all the folder and its mails using the link, (answer ofono2012)
How To Get all ITEMS from Folders and Sub-folders of PublicFolders Using EWS Managed API
but i am not able to get, which folder was whose sub-folder, means not able to get folder hierarchy
please help
You'll have to do a separate FindFolder operation to get the folder hierarchy:
http://msdn.microsoft.com/en-us/library/office/dd633627(v=exchg.80).aspx
Make sure to include view.Traversal = FolderTraversal.Deep; and do
view.PropertySet = new PropertySet(BasePropertySet.IdOnly);
view.PropertySet.Add(FolderSchema.DisplayName);
view.PropertySet.Add(FolderSchema.ParentFolderId);
to get the full hierarchy of relationships. You should then be able to match the ParentFolderId from the items to the folder ids.
I'm a bit confused about where the application should send a bunch of files. Let me suppose that an application accepts a number of images with NSOpenPanel at a time from the user. The application applies graphic filters to them. And it's now ready to save processed files. Before they forced us to sandbox applications, we were allowed to export processed files to application folder in Application Support without NSSavePanel. If you wanted to save files elsewhere, then you had to use NSSavePanel. If the application is sandboxed, it cannot send files to NSApplicationSupportDirectory/{app name}(which points to the containers folder assigned to this application)? My first sandboxed application was rejected a few days ago merely because a text field showed a path to container's application support folder. So if you have a bunch of files to export, you have to prompt the user to ask where to save each file? AppSandboxDesignedGuide, which Apple, Inc. has issued, has nothing to say exactly about where to save files except that it says "Your app has unrestricted read/write access to the container and its subdirectories." I think this PDF guide is a printed version of this web site. I'm asking this question here because I have some doubts and reviewers were often wrong at least when I submitted applications to them two years ago.
Thank you for your advice.
If the files are only for the application itself to use you can save the files in "Application Support/", which under the sandbox is under your container, just as before - just use the APIs to construct the path to that folder (and create it, it doesn't exist automatically, just as before).
If you are outputting files for the user to access then you don't put them in the container - that folder is meant to be hidden from ordinary users, though yours is the first time I've heard that even showing the path got you a rejection, but Apple are pretty random.
Here are three choices of where to put your files:
First is to ask the user. This is what you would normally do anyway, you shouldn't just dump files somewhere.
Second is a situation that the sandbox makes harder - when where the file should is is implicit, e.g. a graphic conversion program might sensibly output the converted file with the same name but different extension in the same folder as the original. This was finally addressed by Apple around 10.8.3 or something with "Related Items" - Apple's docs for this are here. Essentially in the Document Types in the Info.plist you must list all the extensions you handle - both in and out - and add a NSIsRelatedItemType key with the value of YES to all those you might convert between. E.g. For TextEdit .rtf, .rtfd and .txt are flagged in this way so TextEdit can open as one format and save as another.
Third, if you wish to put all your files in one location, say in a "Converted Items" folder. Then you ask the user once to specify this folder and then save a security-scoped bookmark to that folder in your applications defaults or elsewhere in your app's container. On subsequent executions you can access this bookmark and regain access to the folder. For an introduction to this start with Apple's Security-Scoped Bookmarks and Persistent Resource Access. This is really no harder than pre-sandbox as any decent app would always ask for the location of the folder from the user, the difference is the need to save the security-scoped bookmark so the user doesn't need to give permission every time.
HTH.
Let's say my RESTful API deals with files and folders. With it, I can create and edit both files and folders.
A file can belong to a folder. So let's say I want to move a file to a different folder. Which would be most appropriate, according to spec and/or what is most common?
POST to /file/:id, sending the new folder's id, changing the value
for just folder_id, keeping all other attributes untouched. The API
method only updates folder_id.
POST to /file/:id/location, sending
the new folder's id.
This isn't really a straightforward answer but I guess the question I would ask myself is: should the move file action be more appropriate for a file resource or a folder resource to handle. I wouldn't worry too much about the URI structure until I had an answer to the question.
The move action touches three resources; the file, the original folder and the destination folder. A client would need to know at least the file URI & the destination folder URI since the original folder can be inferred. I can see a case being made for both approaches. The file resource representation (the contents of the POST) could indicate a new destination folder as a value which is assumed to empty if no move is required. A folder resource could assume that a file representation contained in a POST implies moving that file to the folder. Whichever approach makes the most sense for your business process is the one I would go with.