MS, you funny!
-
This is why I use .NET :~
Latest Article - A Concise Overview of Threads Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
This is why I use .NET :~
Latest Article - A Concise Overview of Threads Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
In .NET, can you create a program where the save file dialog will default to the user's AppData folder for files like .ini files, and then back to the user's regular folders for their regular files? (I doubt you can, because I think this is a limitation of MS believing they know better than us how programs should work, and overriding their dialogs to disable such use.) If I'm wrong, I'm not going to rewrite, but would be interested to know.
-
In .NET, can you create a program where the save file dialog will default to the user's AppData folder for files like .ini files, and then back to the user's regular folders for their regular files? (I doubt you can, because I think this is a limitation of MS believing they know better than us how programs should work, and overriding their dialogs to disable such use.) If I'm wrong, I'm not going to rewrite, but would be interested to know.
You'd have to write the logic to change the InitialDirectory[^] property based on file type but SaveFileDialog[^] may work for you.
-
Poking around, MS doesn't want you to use
GetSaveFileName
anymore. Instead, they want you to use the 'Common Item Dialog'. So click on that page, and find a function with 11 indentation levels! Copy and paste it, to find that it is part of a sample code, and relies on other functions in that sample. Try to download the sample, and the page isn't found. But you can download an SDK which supposedly contains the sample? Try to run it, though, and you will get a 'Some components cannot be installed' error, and no indication that the samples are included in it. X| Oh MS, you funny! All this because I was trying to figure out a way to allow the user to save program configuration files in the user app work directory, and regular files wherever they wish, but MS, in their infinite non-wisdom, won't allow the directory to be changed usingGetSaveFileName
, because they believe you will only ever be dealing with one type of file for your application. :doh: (Of course, they have the same issue in MS Word, and other Office programs, because they store config files like macros in a special subdirectory until the user changes where they store them. Afterwards, the dialog will default to that special directory until after you change it once. At least that was the case the last time I played with macros in Word.) Double- :doh:Save it in other place and then move the "closed" file there :rolleyes: ;P :laugh: :laugh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Save it in other place and then move the "closed" file there :rolleyes: ;P :laugh: :laugh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
All well and good, until you want to load one of those files! :doh:
-
You'd have to write the logic to change the InitialDirectory[^] property based on file type but SaveFileDialog[^] may work for you.
Interesting. Thanks for the knowledge!
-
In .NET, can you create a program where the save file dialog will default to the user's AppData folder for files like .ini files, and then back to the user's regular folders for their regular files? (I doubt you can, because I think this is a limitation of MS believing they know better than us how programs should work, and overriding their dialogs to disable such use.) If I'm wrong, I'm not going to rewrite, but would be interested to know.
That's correct, you can not save app.config settings in the application directory with C#. I have a simple fix which allows this using file based search and replace, if you want I can send you some code, just let me know :-\
-
That's correct, you can not save app.config settings in the application directory with C#. I have a simple fix which allows this using file based search and replace, if you want I can send you some code, just let me know :-\
Please do, and I'll see if I can pound it into C++. :thumbsup:
-
Please do, and I'll see if I can pound it into C++. :thumbsup:
I will post it tomorrow, as I don't have the source code at home :)
-
I will post it tomorrow, as I don't have the source code at home :)
Cool! :thumbsup:
-
Poking around, MS doesn't want you to use
GetSaveFileName
anymore. Instead, they want you to use the 'Common Item Dialog'. So click on that page, and find a function with 11 indentation levels! Copy and paste it, to find that it is part of a sample code, and relies on other functions in that sample. Try to download the sample, and the page isn't found. But you can download an SDK which supposedly contains the sample? Try to run it, though, and you will get a 'Some components cannot be installed' error, and no indication that the samples are included in it. X| Oh MS, you funny! All this because I was trying to figure out a way to allow the user to save program configuration files in the user app work directory, and regular files wherever they wish, but MS, in their infinite non-wisdom, won't allow the directory to be changed usingGetSaveFileName
, because they believe you will only ever be dealing with one type of file for your application. :doh: (Of course, they have the same issue in MS Word, and other Office programs, because they store config files like macros in a special subdirectory until the user changes where they store them. Afterwards, the dialog will default to that special directory until after you change it once. At least that was the case the last time I played with macros in Word.) Double- :doh:Here is another page with more then 20 Sample code links that do not work: [Shell SDK Samples (Windows)](https://msdn.microsoft.com/en-us/library/windows/desktop/dd940376(v=vs.85).aspx#sample\_list) -> you have to click (for example):Automatic Jump List Sample -> Downloading the Sample -> You'll either end up with page not found or just the SDK Link I don't think its funny and certainly not helpful
-
Please do, and I'll see if I can pound it into C++. :thumbsup:
Here's my code, as you can see it's quite simple:
this.SaveSettings(Application.ExecutablePath + ".config");
/// /// Save the application settings in .exe.config. /// private void SaveSettings(string fileName) { string oldHostname = Properties.Settings.Default.HostnameUrl; string oldSipClients = Properties.Settings.Default.SipClients; string oldVersion = Properties.Settings.Default.LastExeVersion; if (this.textBoxHostname.Text != oldHostname) { this.ConfigFileUpdate(fileName, "HostnameUrl", oldHostname, this.textBoxHostname.Text); } if (this.textBoxSipClients.Text != oldSipClients) { this.ConfigFileUpdate(fileName, "SipClients", oldSipClients, this.textBoxSipClients.Text); } if (string.Compare(this.newExeVersion, oldVersion) > 0) { this.ConfigFileUpdate(fileName, "LastExeVersion", oldVersion, this.newExeVersion); } } /// /// Application config file can not be written to with Properties.Settings.Default, so do a file based replace. /// private void ConfigFileUpdate(string fileName, string keyName, string searchstring, string replacestring) { try { if (string.IsNullOrEmpty(searchstring) || string.IsNullOrEmpty(replacestring)) { return; } searchstring = ">" + searchstring + "<"; replacestring = ">" + replacestring + "<"; string\[\] configLines = File.ReadAllLines(fileName); for (int i = 10; i < configLines.Length; i++) { string linePrevious = configLines\[i - 1\]; string line = configLines\[i\]; if (linePrevious.Contains(keyName) && line.Contains(searchstring)) { // Only replace the first line found configLines\[i\] = line.Replace(searchstring, replacestring); break; } } File.WriteAllLines(fileName, configLines); } catch (Exception ex) { Debug.Print(ex.Message); } }
-
Here's my code, as you can see it's quite simple:
this.SaveSettings(Application.ExecutablePath + ".config");
/// /// Save the application settings in .exe.config. /// private void SaveSettings(string fileName) { string oldHostname = Properties.Settings.Default.HostnameUrl; string oldSipClients = Properties.Settings.Default.SipClients; string oldVersion = Properties.Settings.Default.LastExeVersion; if (this.textBoxHostname.Text != oldHostname) { this.ConfigFileUpdate(fileName, "HostnameUrl", oldHostname, this.textBoxHostname.Text); } if (this.textBoxSipClients.Text != oldSipClients) { this.ConfigFileUpdate(fileName, "SipClients", oldSipClients, this.textBoxSipClients.Text); } if (string.Compare(this.newExeVersion, oldVersion) > 0) { this.ConfigFileUpdate(fileName, "LastExeVersion", oldVersion, this.newExeVersion); } } /// /// Application config file can not be written to with Properties.Settings.Default, so do a file based replace. /// private void ConfigFileUpdate(string fileName, string keyName, string searchstring, string replacestring) { try { if (string.IsNullOrEmpty(searchstring) || string.IsNullOrEmpty(replacestring)) { return; } searchstring = ">" + searchstring + "<"; replacestring = ">" + replacestring + "<"; string\[\] configLines = File.ReadAllLines(fileName); for (int i = 10; i < configLines.Length; i++) { string linePrevious = configLines\[i - 1\]; string line = configLines\[i\]; if (linePrevious.Contains(keyName) && line.Contains(searchstring)) { // Only replace the first line found configLines\[i\] = line.Replace(searchstring, replacestring); break; } } File.WriteAllLines(fileName, configLines); } catch (Exception ex) { Debug.Print(ex.Message); } }
Thanks!
-
Poking around, MS doesn't want you to use
GetSaveFileName
anymore. Instead, they want you to use the 'Common Item Dialog'. So click on that page, and find a function with 11 indentation levels! Copy and paste it, to find that it is part of a sample code, and relies on other functions in that sample. Try to download the sample, and the page isn't found. But you can download an SDK which supposedly contains the sample? Try to run it, though, and you will get a 'Some components cannot be installed' error, and no indication that the samples are included in it. X| Oh MS, you funny! All this because I was trying to figure out a way to allow the user to save program configuration files in the user app work directory, and regular files wherever they wish, but MS, in their infinite non-wisdom, won't allow the directory to be changed usingGetSaveFileName
, because they believe you will only ever be dealing with one type of file for your application. :doh: (Of course, they have the same issue in MS Word, and other Office programs, because they store config files like macros in a special subdirectory until the user changes where they store them. Afterwards, the dialog will default to that special directory until after you change it once. At least that was the case the last time I played with macros in Word.) Double- :doh:David O'Neil wrote:
One more reason to change to .Net. Where do these many circles of hell levels of indentation come from? The lack of a proper
exception
implementation in old-style C/C++. Just look:HResult hr;
hr = /* some function call */;
if (SUCCEEDED(hr))
{
hr = /* next function call etc. */;And in case of error, ... it does nothing. Just the user wonders why it does not work, the service hotline people will be delighted by not having any indication of why things do not work. C# would prefer to throw an exception in case of failure, and no need to handle each place of potential failure separately. Of course, catching the exception and - more importantly - handling it usefully, are still things the developer has to take care of (but it's rather easy).
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!