I am making a little program and I need to be able to remove the Lock attribute from all files (no matter the extension of those files) in the specified directory. I haven't find any way to do so on the web so far, so I really have no idea how to start a basic code for that job, so all I can really do is give you the elements of my Windows Form:
txtDirectory: This is where the directory is being
displayed/selected. All files in the displayed directory needs to be
getting the Lock attribute from them - see btnConfirm to know more.
btnSelectDirectory: This button opens the directory seletion
dialog. This section does not need any code - but feel free to add
code if you think it could improve my program.
btnConfirm: This
button is where, when clicked, all files in the specified directory
will be removed from the Lock attribute. This is what I really
need help with.
How can I do so?
Related
I am trying to open files using a specified executable; just like as if you were to right mouse click on a file then scroll to "Open with"
I tried what kaymaf said and reviewed the docs, but I cannot seem to get this to work.
Dim FI As New FileInfo(GetFileNameFromListViewItem(ListViewCollection.SelectedItems(0)))
Dim GetExif As Process = System.Diagnostics.Process.Start("C:\Users\*username*\Downloads\exiftool.exe", FI.FullName)
This just ends up open the executable and rather than opening the file with the executable.
You would like to open a file with your program using the Windows context menu; and do you want to get an entry in that menu? If that is not correct, the answer can be deleted.
I found this in a German forum, and they refer to this site:
This is the translated text:
One possibility would be that you register your file extension and your program in the system to open this file extension. As soon as the system knows everything, you only need to right-click on the file(s) and in the context menu, in addition to the standard entries, another menu item for opening these files is displayed. If you select this menu item, your program will start automatically if it has not yet started, and you can read out / determine the path to this file or several files in your program and process it accordingly. How it all works is described here: ookii.org/Blog/opening_files_via_idroptarget_in_net
On this page there is also a sample for download (start text files with your own program via an additional entry in the context menu / display paths to the files). It is not a VB, but it should be translatable without any problems. Corresponding information on the page and the comments should be observed.
The main.tex file in my project is the one to be opened in editor view in order to successfully compile the pdf-document. It has several child-files like e.g. content.tex where I write the actual thesis text.
Every time I want to compile the document in order to view the changes I have to change the editor-file to main.tex. Otherwise the process ends with errors.
I already tried the Ctrl+0 base file setting, but it did not show any changes.
The LaTeX project is based on a template provided by my university and though has to stay untouched in regards of the project structure itself (why so ever...).
I managed to do as I strived to. Don't know whether I'd just been too clumsy or if it relates to the problems I faced during the \input{...} integration, but if anyone wonders how to do so too:
It in fact has been the way I already tried - set the main-document to master-document.
Nevertheless I switched to use TexStudio meanwhile.
Thank you for your response #Gowachin
For some reason when I try to do a rename refactor, idea picks up code that is not even remotely close to my project. Furthermore, this code is read-only and I can't edit it! And Non-Project Access dialog is almost mockingly "ultimate" in its options: I can only choose whether I want to edit the non-project files this time or I want to do this ALWAYS. No option to skip these files altogether.
I tried to add these folders as a content root and exclude them - it didn't help. And I can't remove them, since they actually don't show up as files in the refactor preview (they are not referenced anywhere in the project view either), only {m} functions/method do with no option to remove them.
So the refactor rightfully fails because it can't edit RO files. So how would I solve this?
I have an Xcode 4 objective-C project which contains about 150 .m and .h files in it.
The code underlying the project does not always correspond in underlying disk structure to the folders shown in the Xcode project. I get that part.
What I don't get is why Xcode won't tell me anything about why I can create new project groups and move items to them, with no problems, but certain existing project folders will cause the project to become broken, and the code will no longer build once I move certain .m files or .h files into a different group. When its broken it just shows the file in red. This is frustrating and confusing.
In the screenshot below, the left side of image before shows state before, when all is good, right side shows red (missing) file after moving into a group. Given that groups don't represent a folder on disk, I would not expect moving from one group to another to break things. Sometimes it does, and sometimes it does not. This particular XCode issue upsets me a lot.
In the good old days of Friendly Mac User-Interfaces, you could hit ⌘+I and get some information about the properties of objects, or right click and get to the properties of something via its context menu. Groups (folder icons) in XCode projects have no properties item in their context (right click menu) and yet these groups all clearly NOT all alike. What's up with these identical looking groups?
Secondly, how does a person learn how to reorganize both the on-disk-folder-organization and the visual group organization, in a way that does not leave you bloodied and beaten? (XCode 4 is the most difficult IDE version I have ever used, for this, I'm sure I've missed some important documentation on dealing with folders and files and so on.)
Update: The File Inspector (Identity Inspector in Utilities menu) is the key to this mystery, but exactly how a new user is to discover this (other than by painful experience) is still unknown to me. I also don't really understand what all this is about, with various choices available in the Path drop-down, and the blank or non blank value that has no description or help, just a cryptic icon and either a name of some real on-disk-folder or else a gray text field saying None:
This sort of thing doesn't just happen out of the blue. In this case, what has happened is that a user has opened an .xcodeproj and is unaware of the difference between the various relative or absolute Path options that a Group can be a part of. A Group in XCode is always shown with exactly the same manilla color folder-icon inside your XCode project, no matter what modes or properties it has defined inside of it.
By default the simplest case is that you create a new folder Group object in XCode and it's purely a cosmetic organizational tool that has no disk location information stored in it.
This is not the ONLY thing that these groups do, and not the only "mode" that these groups can be used in. These groups can also be used to point at some folder and say "things that are in this virtual folder are really somewhere else, either underneath this project's main folder in a subdirectory, or even up somewhere else on your hard-drive, either stored in relative path, or absolute path format". When used like this, these things remind me of a Windows "Shortcut" object on the desktop, or a Mac "Alias" object in the finder.
Dragging a file from one group to another does not move it to a different folder on the disk. It simply moves a reference to a file with a certain name, to another group, which might mean that after you drag a file, you haven't really moved it, or copied, or relocated it in any way, you've just moved an alias from a place where it could resolve properly to a real file, to a place where it can't. Thus XCode helpfully turns it red for you, without any helpful error message about what happened.
How do you fix it? In this case, go to the Identity inspector pane in the Utilities menu, and either decide to clear out the bogus value in the place where I have shown in the picture in the original question where I had "Classes". Clearing out a value that is invalid is not exactly easy to do because XCode requires that you basically find the root folder of your project and select that, and that will 'clear" the relative or absolute path property on your folder-group.
Alternatively, you can leave the folder alone, and just don't drag files from group A to group B without first checking what relative or absolute path they reference.
What still seems horrible to me is that XCode tutorials tell you to "use XCode to manage your project's contents, don't just drag files around in the finder inside an XCode project directory", and that's good advice, but it leads me to assume that XCode provides full and intuitive physical (and virtual) group-folder organization tools. It does not. As an example, imagine you inherit a project that has .m and .h files scattered through four physical folders underneath the main XCode project folder and you want to move those files around. You have to do a combination of tricky things inside XCode, and either in Terminal or in the Finder, in order to reorganize your folder. With the complications involved in moving items around in your version control tool of choice added upon the top of that, and XCode's very limited support for only Git and Subversion, you have a really tricky mess.
I have a VBA macro which runs in Word 2003. It is one module and the code attached to a userform, and it goes to about 30 client sites. When I first rolled this out I sent someone round to each site to place a .dot template in the Word Startup folder of each of 30 boxes, which then makes the macro appear as a button on the toolbar for each user.
All the users are internet connected.
The location of the .dot template varies from machine to machine, so "installers" would be out of play I presume?
I am anticipating that the macro made need to change from time to time. Is there any way I could get the user to press a button to get the macro to update itself?
Whether its push button or auto run checking for update, I would presumably need to know how to determine where the macro is running from (path) without a document necessarily having been saved, and how to find path to the Startup folder tools>options>file locations but programatically .
This can be done.
create 2 .dot files, loader.dot (checks for updates) and worker.dot (the main macro you are using and want to be able to update automatically).
the first loader.dot should go into C:\Program Files\Microsoft Office\OFFICE11\STARTUP
This is a trusted location and the macro will be loaded into any Word document. Use an AutoExec() subroutine to ensure it runs whenever a word doc is loaded.
worker.dot can go in any fixed installation location e.g. C:\yourapp\worker.dot
The logic in loader.dot is remove any reference to worker.dot (I had to enable trust of VBA model in macro security settings) check for an update using an http call, if new version available download it overwriting worker.dot, then add reference from file specifying worker.dot
I'm not sure that the user-presses-a-button model is ideal.
I'd look into building a "loader" template. Its job would be to run at startup and look for updates to the template/macro you already have and download/install/whatever such files when they change. Then load whatever's installed locally for use.
You should also think about whether it's a problem if an update is available but someone doesn't use it (perhaps they started Word before the change was uploaded, or they're offline). Also, do you need to know what version people are using? Have your loader report back, via HTTP, email or some other method (Twitter?)
Any such loader needs to either very stable (otherwise you just replace chasing around replacing the target template with chasing around replacing the loader) or able to update itself when necessary.