I'm trying to save some screen dumps to internal storage for debugging purposes, but I can't seem to get access to them. When I call FileSystemStorage.getInstance().getAppHomePath(), I get a path that looks something like this:
/data/data/com.mycompany.myapp/files/
But I can't see this folder in the Android File Transfer tool, so I can't drag the files to my Mac. I also tried attaching them to an email using the Message class, but for some reason the attachments never showed up. I notice that a lot of applications store data in folders like this:
/Android/data/com.doubletwist.androidplayer/
If I try to create a folder like this, I run into two problems. First, it's not platform independent. (This doesn't matter much because I'm just doing this for debugging.) Second, it doesn't work. I get an error telling me I need to use the directory returned by FileSystemStorage.getInstance().getAppHomePath()
Is there any way I can save files to a folder that I can actually retrieve them from? It would be more helpful if I had a platform-independent way, but any way that works is fine for now.
File system is a very "unportable" notion. By default app home is a private folder which some mobile OS's including Android 4+ keep private and inaccessible.
Android has a concept of "sdcard" which used to be a physical storage where you could write anything in any directory without a problem. This is no longer applicable for later versions of Android but you can read from the sdcard directory and detect it.
FileSystemStorage has an API to get roots and their types, if you have an sdcard type you can read from there. You can use the FileTree to see the file hierarchy as exposed to your application which can be useful for debugging.
Related
When I create a new STM32CubeIDE project, it default saves it to my /Documents directory. This isn't too bad except I like to have a folder for each application so that it isn't just a bunch of files. I tried creating a folder called "STM32CubeIDE" to save new projects to, put it gives me an error: "overlaps the location of another project".
I've done some googling and found that this issue also exists in Eclipse (which makes sense) but couldn't solve my problem from those solutions.
I was also wondering if there is a way to move all of my existing projects to this newly created folder? Last time I tried, the IDE flipped out on me and couldn't find my stuff.
First of all, do not call your folder "STM32CubeIDE" if this already exists. Use a different name, because this is normally used by default and it may cause issues (probably the reason why you are getting that error).
When you install or update STM32CubeIDE it gives you the option to choose where you want your default folder to be. For example, my default folder is
C:\Users\%USERPROFILE%\STM32CubeIDE\workspace_1.6.0\
Now if you want to use different folders for different projects, there are two options:
You can Export your project (application) to a desired folder and then Import it using the File tab. This is a good method if you want to make backups, or just want to make sure that all relevant files are transferred correctly to avoid "missing file" issues.
The other method (my favourite) is to simply copy you project folders and paste them to a different folder, wherever you want to put them. Then you simply open STM32CubeIDE, go to File > Open Projects from File System... and chose your project. You might get a pop-up about software compatibility issues (if you made an update), etc. but this should open up your project and show it in the Project Explorer.
I am using Serilog in my UWP application. I can write the log in App LocalState folder without any issue.
But now I want to write the logs in D: drive specific folder. I have added the broadFileSystemAccess restricted capability and enabled the full access from the settings.
But still it is not creating the file in the specified location and not raising any error.
Anyone know the fix for this? Thanks in advance.
var file = #"D:\Logs\Serilog.txt";
Serilog.Log.Logger = new LoggerConfiguration().WriteTo.File(file).CreateLogger();
There is a very important information about broadFileSystemAccess capability on the File access permissions document. I'm not sure if you note it.
This broadFileSystemAccess capability only works for APIs in the Windows.Storage namespace.
This point is very important. So, your issue actually is you need to check the LoggerConfiguration().WriteTo.File(file).CreateLogger() relevant method if it write to files by using the Windows.Storage APIs.
By my checking, it uses the StreamWriter method to write to files. But this method is not included in the Windows.Storage APIs. So, the issue was very obvious. You need to submit this issue to Github and let the officials to modify this method and make it work in UWP.
Or, if you're interested in serilog-sinks-file source code, you could download it and make the change by yourself, Then, you could compile a custom serilog library version for your UWP project.
It is a little tricky to describe my question, but I'll try my best.
First, I am developing a Multi-Document-Interface app using C and WinAPI. My program is able to parse command line arguments to open multiple files. I put this string:
"X:\MyAppName.exe" "%1"
under the open with command list of the txt files so that now I can right click any .txt files in Windows Explorer and open it with my app. However, when I select multiple files, the explorer runs command "X:\MyAppName.exe" "%1" multiple times so that multiple instances of my app are started.
But wait! That's not the most tricky part. Instead, it is that my app treats opening a single file and opening multiple files at a time as two different things with seperate visual styles. I know the idea of keeping one instance running at a time (though I don't know the C code to implement it). But I don't know how to tell the difference between open several files one by one and opening multiple files at the same time.
I hope I make it clear.
Using the Registry like you currently are, you will not be able to directly differentiate between multiple files from single files. Each requested file will start a new copy of your app, as you have already noticed. If you implement single-instancing (which is not that hard to do), what you could do is detect when the first file is requested and start a short timer, then have each subsequent file reset that timer. When it finally elapses, check how many files you collected and act on them as needed.
A better, and preferred, solution is to instead create an out-of-process COM object in your app that implements the IDropTarget interface. Windows will then be able to funnel file information through a single entry point into your app. Your app will not have to care where the information is coming from. You will be able to support not only multiple files at a time, but even different formats of file information (Windows could pass you just the file names, or it could pass you the actual file data itself).
Windows will construct a single IDataObject object to hold whatever file information is needed, and will then pass it to your IDropTarget object. If your app is already running, COM will be able to access your existing IDropTarget object. If your app is not already running, COM will automatically start your app before then accessing its IDropTarget object. Either way, once it is running, your IDropTarget can look at whatever data is passed to it and decide whether to accept it or reject it.
If you register your COM object's CLSID as a DropTarget for the desired file extensions, users will be able to double-click on such files, or select such files and press Enter, and they will be passed to your IDropTarget object.
If you register an AppPath for your app and then register the CLSID as a DropTarget for it, users will be able to drag files, regardless of extension, onto your app's exe file itself, and they will be passed to your IDropTarget object.
If you use the same COM object with the RegisterDragDrop() function, users will be able to drag files, regardless of extension, onto your app's UI directly, and they will be passed to your IDropTarget object.
I have started coding an FTP client application (for fun). I’m trying to represent remotely hosted files with icons. For example, let’s say I’m browsing the root folder of an FTP server (/) and want to display the Backup.zip file with the icon association from that client operating system. On some systems, this may be the windows compression icon and other operating systems this may be WinZip or WinRAR icons.
I have the client browsing local files with the SHGetFileInfo() function. This works great with files that are local, however, this function requires the physical file in order to retrieve the associated icon. So, this will not work with remotely hosted files. I have found some samples of loading icons given a file extension, and this is really where the question comes in... What would be the best strategy to get icons associated to remote files?
Go to the registry every time and look up extension to icon associations
Create 1 byte files with each extension and use the SHGetFileInfo() function for remote files (using local 1 byte files as association for remote files)
Other strategies???
What would a professional software company creating an FTP client do?
Thank you for your time.
-Jessy Houle
I suggest that you don't go to the registry every time: go if you need to, but if you've already been for a given filetype then remember/cache that result (within your program) and reuse it.
Use the procedure here from a previous Stack Overflow question on the same idea and uses the registry instead of an actual file.
How can I get the filetype icon that Windows Explorer shows?
Is there any way to have something that looks just like a file on a Windows file share, but is really a resource served up over HTTP?
For context, I'm working with an old app that can only deal with files on a Windows file share, I want to create a simple HTTP-based service to serve the content of the files dynamically to pick up real time changes to the underlying data on request.
WebDAV (basically) takes an existing directory, and shares it over HTTP - which sounds like the opposite of what you want.
You need something that speaks SMB/CIFS on one end, and your own code on the other. The easiest way to do that is with a userspace file system.
To that end, here's a couple of links:
WinFUSE, which is kind of a barebones CIFS/SMB server that can host your own filesystem. I've done a couple of small samples with it - and the docs are terrible, but it more or less worked.
Dokan, a userspace file driver with .NET bindings. I haven't used this one, but it looks promising. It has both .NET and Ruby bindings, so you should be able to get a POC up pretty quickly.
Callback File System - yet another userspace file system. Again, I have no experience with this one.
A Linux box with SAMBA and FUSE that shares the drive out to the Windows box.
This won't answer your question in any meaningful way, but maybe it will get you pointed in the right direction. Look into serving the "file(s)" via WebDAV--SharePoint uses this and its files can be accessed exactly as you want, as a file share where the transport mechanism is HTTP. Unfortunately I can't give any more detailed info, as I've only worked on the client end of WebDAV and not the server side of things.
I think serving up files from WebDAV might be what you're looking for.