When I start typing a try/catch block, ReSharper causes it to be expanded from
try {
to
try
{
}
catch(Exception)
{
}
I appreciate ReSharper trying to do me a favour, but this is one of those instances where I'd prefer to do it myself seeing as I'm often going back and adding the try block later, or typing a try/finally block without a catch clause.
Where do I turn off this behaviour in ReSharper?
ReSharper menu / Live Templates
Under Predefined Templates / C# / Imported Visual C# Snippets
Uncheck try and tryf.
Related
This is an extremely strange issue- I have some Powershell code and a XAML GUI I made with Visual Studio for a fairly basic app for users. I'm fairly experienced with Powershell, but completely new to XAML.
Here's the code snippet:
`
$var_RKH.Add_Click({
$targetSite = $RKH
$var_TargetSite.Content = "Rock Hill"
})
`
Somehow, $targetSite is still null after this click event. I've confirmed the var $RKH contains the needed data. In another click event on another button, I copy-pasted that same line and it works. However, what's absolutely twisted my brain is- the third line works. The $var_TargetSite.Content variable is correctly updated.
So the click event is definitely firing, the second line just gets completely skipped somehow, and the third line works fine. On other click events, the exact same code works fine. I must be missing something very simple because this is absolutely twisting my brain.
Script blocks aren't really scopes. They're script blocks and do not inherit from enclosing scope. Instead, you pass values into it just like you would for a thread in C#. This can get confusing because both scopes and script blocks get the {} delimiter -- they're not the same though and not interchangeable either:
[scriptblock]$Sb = {'This is a test'}
if($true) $sb
will throw a ParserError exception rather than print 'this is a test'.
Please be very careful about "sideloading" variables, especially with WPF; there is a high degree of multithread in any WPF application and you literally don't know who is going to access what when.
If you can, try to resolve the value of $RKH inside the script block rather than try to force it in.
Or you could implement code-behind for the XAML and put both .xaml and .xaml.cs in an assembly, then use that in PS.
Okay So I am working on a project and trying to make it neat and visibly understandable where everything is is difficult. To my knowledge Xcode doesn't have an Indent Guide, but something is does have is the ability to collapse the code inside {} like this:
This can work for any {}. I want to make my code easier to read, so I am trying to use this effect inside of a case, so it is easier to see all of the cases at once, I did this:
switch transition {
case .SlideOutside:
{ /* Error */
print("Pretend that there is hundreds of lines of code here.")
}
break
default: //The Default will be Fade
break
}
But I get the error
Braced block of statements is an unused closure
On line 4 with the opening bracket. I don't know how to fix this, could somebody please help.
This sentence
and trying to make it neat and visibly understandable
and this one
Pretend that there is hundreds of lines of code here.
are not very compatible :)
Solution 1
Writing
{
/* Error */
print("Pretend that there is hundreds of lines of code here.")
}
you created a closure but you did not run it. To execute the block you need to add () like shown below
{
/* Error */
print("Pretend that there is hundreds of lines of code here.")
}()
Solution 2
If you really are putting hundreds of lines inside a switch case I think you should better struct you code.
The first thing to do is moving all that code inside a function in order to put only the invocation of the function inside the Switch Case.
switch transition {
case .SlideOutside: slideOutInside()
default: fade()
}
Next you should look at that function with hundreds of line and manage ti split it into subfunctions (and so on).
I wonder how a try-catch block is evaluated in matlab. In particular, is the try-catch block evaluated in runtime or "compile time"?
Also, is a try-catch block expensive?
If someone have a link to any documentation that would be much appreciated.
(Btw, I know that try-catch is not the best solution in most cases. Still I would like to know how it works, since I have used it in some code).
try and catch blocks allow you to override the default error behavior
for a set of program statements. If any statement in a try block
generates an error, program control goes immediately to the catch
block, which contains your error handling statements.
To learn more about try and catch in Matlab:Try and Catch
Try and catch block is always executed in run-time and is used to catch the errors that occur and has error-handling statements. So if your code generates some error and you want to handle it, use it. Using error-handling is good programming practice..
I wrote this simple AHK script, it's working. But rightclick systray icon- suspend/pause, it just still keep working. Is it because of something in my code? or about win7 x64?
#Persistent
return
OnClipboardChange:
WinGetActiveTitle, OutputVar
IfWinExist, collect.doc
{
WinActivate ; use the window found above
send,^v
send,{Enter}
winactivate,%Outputvar%
}
else
tooltip,need collect doc,400,400
Sleep 100
return
Both Pause and Suspend are not meant to block automatically called subroutines like OnClipboardChange or GuiClose. Pause merely blocks the current thread, which means that every newly created thread will still run, and a clipboard change does create a new thread. Ergo, Pause can't block it.
In such cases, you need to implement an own piece of logic within the "event subroutine" that checks some kind of state.
Going with your premise to make the functionality depend on the paused state, a fairly easy way would be to check for the built-in A_IsPaused:
OnClipboardChange:
if(A_IsPaused) {
return
}
msgbox, 'sup?
return
There are certainly many ways to implement this. You could also define your own hotkey to activate/deactivate/toggle a custom state.
P.S:
Activating a window only to paste some text seems a bit unnecessary and bothersome to me; have a look at the Control commands (e.g. Control, EditPaste) or access Word via COM. Depending on what you do, I believe directly writing to a text file and/or in-memory storage might be a better alternative to a running Word instance anyway.
P.P.S:
You might want to be careful with such a negligent clipboard logger. I assume you don't want every kind of data (e.g. passwords) showing up there.
I'm debugging a heavily assert()'ed iPhone app (Xcode, Objective-C++, and device simulator). In some cases, the assert failure would just terminate the app, instead of breaking into the debugger as I'd expect.
I made a workaround by implementing my own kinda-assert to the effect of:
#define AssertLite(b) if(!(b)) {asm {int 3}}
(fluff omitted), but I wonder if anyone ever encountered this. I could not determine a pattern as to when does it break and when does it terminate. The code is not threaded; all it does is done in event handlers.
Why does this happen and how do I make vanilla assert() behave like a conditional breakpoint it should be?
First off, since you are working on an iPhone app, you should probably use NSAssert() instead of the vanilla BSD assert function.
e.g. NSAssert(the_object, #"NIL object encountered");
The NSAssert macro will throw an Objective-C exception (NSInternalInconsistencyException) if the assertion fails.
Since your goal is to break on the exception, the next step is to make the Xcode debugger break on Objective-C exceptions. This is probably a good thing to do anyway.
In the Breakpoints window (Run->Show->Breakpoints menu item), click where it says "Double-Click for Symbol" to enter the symbol -[NSException raise]
The last thing to be careful off is that NSAsserts do not compile out in a release build. That means that you have to either be prepared to handle the exception in your application, or you need to create your own macro that does compile out in release builds.
Here's the macro I use to compile out assertions in runtime code (note that I then use HMAssert in my code instead of NSAssert):
#ifdef DEBUG
# define HMAssert(A,B) NSAssert(A,B)
#else
# define HMAssert(A,B)
#endif
This requires a DEBUG preprocessor macro to be defined. Here's how to set that up:
Right-click on your project in Xcode. That will be the top item in the left panel where your projects files are listed
Select "Get Info" from the context menu that pops up.
Go to the "Build" tab.
Make sure the "Configuration" is set to "Debug".
Type DEBUG into the field next to "Preprocessor Macros" under "GCC 4.2 - Preprocessing".
First of all, if you "Add Exception Breakpoint..." in the Breakpoint Navigator (⌘6), the debugger will stop on NSAssert's failures, allowing you to look at the stack and understand what went wrong.
You should use the standard NSAssert. If you use it correctly, there is not a lot that you need to manually create -- everything Mike mention is similar to the default NSAssert implementation.
You should run you release configuration with NS_BLOCK_ASSERTIONS set in your precompiled headers (follow Mike's steps), to disable assertions. If you need more info on why to do so, check out: http://myok12.wordpress.com/2010/10/10/to-use-or-not-to-use-assertions/
In Xcode 4 and new iOS, NSAssert may actually take a variable list of parameters. This may be useful to log some values together with the assert. The compiling-out assert (see answer by Mike above) could be defined like this:
#ifdef DEBUG
# define DAssert(A, B, ...) NSAssert(A, B, ##__VA_ARGS__);
#else
# define DAssert(...);
#endif
Also, there is no longer Run → Show → Breakpoints menu item. See this post to set up Xcode 4 to break on an assert as defined above.
One time I saw a different behavior from the assert() calls once. It was caused by the compiler picking up different macro definitions at different portions of the build process.
Once the include paths were straightened out, they all worked the same.