I have a number of files in a give folder A. I want to move these files to folder B one by one. i.e., I am doing processing to every file. so after my own processing completes, I want to move the processed file to a different folder. How can I do that?
Please help!
The pure VB6 approach, without using FileSystemObject, is to copy then delete.
FileCopy src, dest
Kill src
Links to manual:
http://msdn.microsoft.com/en-us/library/aa243368(VS.60).aspx
http://msdn.microsoft.com/en-us/library/aa243388(VS.60).aspx
you can actually use the name function for moving files using VB
Name "c:/test1.txt" as "d:/temp/blabla.txt"
You probably want the FileSystemObject:
https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-1050078.html
Also, obviously you should upgrade and avoid any new vb6 development if possible. If you are .NET enabled however, you can do it much more easily in a .NET library and then expose the .NET component to COM for reference by your VB6 app. The only new requirement would really be that the app requires the .NEt Framework (which is standard now for windows installations). Another benefit of this is that if you later decide to upgrade the app to .NET you already have this functionality done!
Related
I have a game that was originally written in QuickBasic in the 1990's. I converted it into a Win32 app using QB64. I then used Microsoft's Desktop App Converter to package it as a UWP app and submit it to the Microsoft Store (it's been accepted).
The game seems to work fine, except for saving files. It throws a permission denied error whenever you try to save a file. From what I've been able to find thus far it seems that UWP apps can't save in the install directory and that is likely what my app is trying to do.
There are a number of code samples available online for taking a Win32 app written in C#, C, C++, etc. and having it use LocalAppData instead. Unfortunately, I'm not seeing anything that will help me with this application.
Is there a way to make saving files work in this instance? I'm hoping that there is perhaps a way to say, "Hey, when I say save a file, I mean save it to the LocalAppData folder for this particular application." This probably needs to be abstract, ideally a declarative part of the appx package that isn't in the QB64 code. Any ideas?
There are two options to fix it (and one way to hack it):
If the file saving is done from your code, change it to write to an accessible location instead, such as localappdata or temp.
If the file saving is done in code you can't change, then you can use the new Package Support Framework to apply a fixup at runtime that redirects the file operations. This is a new framework coming as part of the 1809 update for Windows 10. At the time of this writing this may not be an option for you just yet. Here is the documentation:
https://learn.microsoft.com/en-us/windows/uwp/porting/package-support-framework?context=/windows/msix/render
A hacky way to solve it that you could try would be to add a launcher EXE to your package and make that the app's entrypoint. The launcher would then copy your actual EXE to a writeable location (localappdata, etc.) and then launch it from there. All your file writes will then succeed.
The way I am going to do is create a SolutionItems directory inside my solution and physically copy all referenced third-party dll files into that folder, then I change reference to that local copy inside the SolutionItems directory. But the question is: does it worth the trouble of manage it manually?
I would think it is a good idea as it is dependency for my application. Without including the dll file, the whole solution wouldn't be able to run inside Visual Studio if the machine don't have the required DevExpress version installed. My Deployment Project will handle dependency correctly regardless, as far as the reference been setup properly.
On the other hand, because DevExpress will normally automatically add references, and I can using Project converter to update version of DevExpress. So without reference to the Local Copy inside solution, it is pretty much working out of the box whenever I am changing reference, or change between DevExpress versions. If instead, I am managing my local copy, I am create more work for myself to maintain the reference and physical copy of dll files. Should I keep it simple as it is now, base on the assumptions that whoever working with this application will need have a copy of DevExpress installed?
We had a similar problem where I work. 5 devs, 1 svn and mulitple copies of DevExpress dlls floating around. We tried at first maintaining a local copy (updated manually) as you describe, this did not work well for us. So yes, the easiest thing to do (in my experience) is require everyone who works on the project have a copy of DevExpress installed.
I'm looking for general advice. I created a Visual Studio 2010 project that outputs an ocx file that is used on XP and Vista machines. The DLL on which it depends has been updated on our Win7 machines. I simply needed to rebuild for Win7 using the exact same code with an updated .lib file. I created a second project configuration (ReleaseW7) and it only differs from the original project config (Release) in that it points to the new .lib.
So now I have 2 files both named xx.ocx. Besides looking at the name of the folder each file resides in (or looking at the creation time of each) there is no way to determine which is which. I thought of using different file version numbers but as far as I can tell (and I'm relatively new to this so I could certainly be wrong) that would require two separate projects each with a slightly modified resource (.rc) file, instead of simply having two configurations within the same project. If nothing more, that seems like a waste of hard drive space. It also feels like the "wrong" way of using file version numbers
Is there a cleaner or more "standard" way of handling this? All I really want is a way for the folks who install the ocx and support the end user to know for certain that they are working with the correct file.
Long story short, I decided to use different version numbers. I was able to setup a preprocessor definition for the resource compiler and use that to handle different versions of VS_VERSION_INFO in my .rc file.
In case anyone is interested, this is the resource I found:
http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/605275c0-3001-45d2-b6c1-652326ca5340/
My compact framework application is generating a ...asmmeta.dll file in the output folder. What exactly are these files and why are they created? I have made compact framework applications in the past and it hasn't created any files like this.
One possible reason (you've not said a lot about what you're building) may be that you have USerControls or custom controls of some sort. In that case, the asmeta files are created for Studio designer support of those controls. Do you also have an XMTA file in the project?
I have a requirement where I create many swc files (swc files are similar to zip or jar files). I want that, whenever I create a new swc file and add it in a "particular folder" then these files should automatically get extracted (similar to what happens in Apache Tomcat webapps folder). Please help me how to do that in Windows.
[Note: I know I can write a ant/rake/gradle script which can do this for me, but just to explore more in Windows how to achieve this]
Use the FileSystemWatcher class if you're using .NET. (here)
If you are not using .NET, then you can use the FindFirstChangeNotification function to listen for filesystem changes.
If you want to do it in a windows scripted fashion, you would use a WMI Event Watcher.
http://technet.microsoft.com/en-us/library/ms141130.aspx
you could use the .NET FileSystemWatcher to do this task. (from withing c#, vb.net, etc..)
with FileSystemWatcher you can observer creation, deletion and modification of files and react to those events.
FileSystemWatcher is the obvious choice in .Net.
IMHO, its not a good component. Many a times it raises double events for change of files and I have not been able to do a neat implementation using FileSystemWatcher.
Don't use .NET (for kids)
Use Win32 api notifications (8 lines of code)