When I use IO.Directory.CreateDirectory to create a directory it creates a read-only directory no matter where I make the directory. Am I missing something?
You are getting confused by the shell properties dialog:
The Read-only checkbox is a tristate checkbox. When it is filled solid like that, it means the state is "indeterminate'. Click it twice to turn it into a check mark. When you then hit the OK or Apply button, the shell sets the readonly attribute on all the files inside the folder.
Yes, this is not great UI design, you are not the first to be tripped up by this. The (only applies to files in folder) hint looks like a fairly desperate attempt to make it clearer. Without enough room to make it a grammatically correct phrase. Wonder what it looks like in German...
Related
Is there a way to make the language property list shorter? Make it show only EN-US and PT-BR, for instance, so it's easier to find them?
You probably don't need to do it.. You can likely just make your life easier like:
Make a new form, lets say it's called LocalForm.vb
Drop a label on it, lets say called HelloLabel
Set form to de-DE, set the text of the label to Hallo
Set form to fr-FR, set the text of the label to Salut
Set the form back to (default) - you now have LocalForm.resx, LocalForm.de-DE.resx and LocalForm.fr-FR.resx and you can add controls
Add a Button, called StartButton
Double click the LocalForm.de-DE.resx file
Dismiss the "if you mess this up you'll have to fix it yourself" dialog
Add a line for StartButton.Text Starten
Repeat for other language files
Dropping a control named XyzButton on the form, and then visiting each LocalFor.*.resx in turn and adding the locale for it is a lot easier than back-and-forthing with the language setting, though I know why it's done the way MS chose to do it - you're supposed to lay your form out perfectly with all its hundreds of controls, and then switch to French and write all the French for all hundreds controls, and then switch to German and write it all in German.. In a use case like that there isn't a lot of work to do with that awkwardly huge Language dropdown. Incremental adds that way are a bit of a pain..
Perhaps raise a connect bug/feature asking them to put the "already used" languages (as determined by the presence of Form.*.resx files) at the top of the list, and wait many years for it to be implemented :)
Note: There's a bit of a nuisance with this "edit the resx" in that if you rename a control it doesn't always get picked up. Last time I was localizing I threw together an app that watched (FileSystemWatcher) files named *Form.resx and if it saw a change (load the current version, compare to the prev version) that was a rename, it made the same change in the other files (or maybe alerted if they weren't in sync.. can't quite remember now and I've no idea where the code has gone)
Maybe don't rename your controls after you first decide a sensible name for them/add them to the translated resx..
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
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?
I have been writing some VBA code to produce charts automatically, and at one point named a variable "CHARTTITLE" not realizing that this is a member of the Chart object. I have deleted this variable upon realizing my mistake. However, since doing so, wherever I employ something like
Charts(1).ChartTitle.Text =
It will automatically auto-capitalize to
Charts(1).CHARTTITLE.Text
I have tried search and replace over the entire project from .CHARTTITLE to .ChartTitle to no avail. I have also tried employing Option Explicit also without effect. I am worried that there is now some sort of memory issue or that I've overwritten something important. Is there any way to reset this back to its default state?
It's a benign effect and it's a long-standing bug relating to the way that VBA stores itself internally. A couple of things to try:
Change the first occurrence of CHARTTITLE in the module, or if in multiple modules in the first module that appears in the project explorer.
Export the module, remove it from the project, edit it using your favourite text editor and reimport it.
CyLog’s WildRename is a good program for performing batch-renames on files. The problem with it is that while the main window is resizable, it does not have the maximize box which makes it a little frustrating to size and use. Moreover, they have not made any updates in a long time, so the program is essentially discontinued.
I ran WildRename and used WinSpy++ to modify the style of its window to manually include the WS_MINIMIZEBOX style and bam!, it was now functioning as expected.
The question now is how to make this permanent.
My first instinct was to fire up ResHacker, but the problem is that the style that needs to be modified is that of the main window of a non-dialog application, so ResHacker has no way of doing this.
The next thing I tried was to open it in a hex-editor, to find the address(es) of the string corresponding to the titlebar. I then opened the file in W32Dasm and located the address of the code that references the address of the titlebar string. I did all this in an attempt to find the location of where the main dialog is created so that I can modify the style passed to CreateWindow(). Unfortunately, I cannot find a call to CreateWindow anywhere near the reference to the titelbar string and none of the calls to CreateWindowEx that I can find seem to be (obviously) the ones used to create the main window.
Is there an easy/automated way of modifying the style of the main window (assuming a non-dialog application)?
You could use a debugger like OllyDBG to dump the exe memory after the edit with WinSpy++, then use that exe or compare the files to see where the change is if you want to see what you've missed
There has to be a call to CreateWindow/Ex(), especially if it not a dialog from a resource. You just need to look harder. I would use IDA instead of WinDasm. It will decompile the assembly into more understandable code, and it has a built-in debugger. You can put a breakpoint on the title string and see in real-time which code actually touches it, and then follow it back to the accessing code.