|
David_Pollard wrote: I'll take my question else where if you still think it isn't appropriate here Don't worry about it, but in the future, choosing the correct forum means the people who see your question are the ones who are most likely to be able to help!
A positive attitude may not solve every problem, but it will annoy enough people to be worth the effort.
|
|
|
|
|
I am developing an activex control for use with ie. The javascript code responds to dragdrop event and calls activex control's c# function. At this point I need to gain access to clipboard and retrieve custom data based on format code. There is an interface IDataObject which could be used for that. But I need to gain access to parent form. Is there a way to access browser form from activex control? If you know of a better way to get to the same clipboard data, please, let me know.
Any help is appreciated.
Thanks in advance
|
|
|
|
|
|
Where's the definition for .subFolderField?
The getter and setter don't make sense.
A collection that triggers OnPropertyChanged events is generally defined somewhere as an ObservableCollection.
|
|
|
|
|
|
|
|
You didn't read the whole thing ... I would consider the last entry on that page ... using your array and a partial class, if need be.
|
|
|
|
|
|
I was suggesting it as a "pattern".
If you can't apply it to your situation, then I don't know what will.
|
|
|
|
|
Hi
We have a standard application that uses AD sso, using forms authentification.
Before last upgrade of this system I wrote a small c# code that opend a browser with a different account than computer user account.
Witch worked fine becuse windows auth. where used then. So user become that new user instead of computer user.
But when they switched to forms auth. in IIS this no longer works. I have no clue how to trick authentification mechanism in this case. Any who hade done this?
Described in Another way;
User (AD-user), let say ABC is logged in to computer. But whants to start application (webpage, IE) as user BBB.
And no, I cant get any Changes in application itself.
\Jonas
|
|
|
|
|
Simplest way will be to programmatically populate the username and password boxes then click the login button.
|
|
|
|
|
What do you mean?
If I browse to the application my computer AD-account is automaticly used. No login page is used.
Starting browser like "run-as" doesn't help. (that works if win.auth. is used in IIS).
What credidentials is forms auth using? Doesn't seem to be browsers cred.
\jonas
|
|
|
|
|
After carefull reading and understanding this link "http://www.codeproject.com/Articles/42258/Particle-swarm-optimization-for-function-optimizat".
I was trying to use the code , but because i am using Visual Studio 2012 and the code is from 2009 maybe the errors that i found were because of the evolution of the C# languange.
Can someone with C# experience help me update the code for the new Version ?
|
|
|
|
|
If you have questions about the code in an article, use the forum at the bottom of the article[^] to ask the author.
The person who wrote the code is the person most likely to be able to help you with it.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Sample 1:
foreach(int i in integerList)
{
try
{
// Do something which might throw exception
}
catch(InvalidOperationException)
{
continue;
}
}
Sample 2:
foreach(int i in integerList)
{
try
{
// Do something which might throw exception
}
catch(InvalidOperationException)
{
// Left blank
}
}
Question: In sample 1 we have "continue;" in catch block and in Sample 2 we have NOT written anything. Are they doing the same thing? If yes, which one is better practice?
modified 11-Mar-15 8:55am.
|
|
|
|
|
They are both various shades of bad practice. You're just catching ANY exception here, without actually bothering to do anything about it. In both cases, the behaviour is the same - the loop keeps on iterating, but the reality is that you have just consumed something that has gone wrong. That is bad practice, so I would urge you to do neither case. Exceptions are thrown for a reason. Only catch them if you intend to do something with them, such as logging or you have logic in there to mitigate the effect, e.g. you might have some retry functionality that you need to use. Ignoring exceptions is the wrong thing to do.
|
|
|
|
|
Thanks for your reply.
I am catching InvalidOperationException instead of general exception (will update the question). However, we have plans to get logging in catch block instead of continue or blank.
The only reason I wanted to ask this, because I wanted to know if writing continue is bad instead of leaving it blank.
--> Our aim was to not do anything for the iteration where an exception is thrown.
|
|
|
|
|
Leaving it blank is bad: it "swallows" the exception, so that nobody ever knows it has happened. So the underlying problem never gets fixed until it has reached massive proportions.
If you are going to add logging later, then re-throw the exception (so you know it occurred in development) and add a TODO to the code to remind you to fix it:
catch(InvalidOperationException ex)
{
throw;
} Adding the TODO means it comes up in the Visual Studio Task List[^] automatically.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Thanks Everyone for the information.
|
|
|
|
|
+5
Small addition: If you catch Exceptions to log them or to do anything else that doesn't include mitigating the error, re-throw the exeption at the end of the catch-Block, either with "throw;" to re-throw the exact same Exception or by throwing a custom Exception and providing the original Exception as an InnerException to the constructor. See here: Anti-Patterns and the Solutions[^] especially the part "Error Hiding Anti-Pattern".
|
|
|
|
|
I would think hard before even trying to put a try ... catch block "inside" a foreach loop.
Exception handling can be expensive. If you were looping "thousands" of times, that would potentially mean "thousands" of exceptions.
An exception "inside" a loop, generally doesn't happen just once because the data / processing requirements are usually similar.
(IMO) One generally wraps a loop "inside" a try ... catch block; not the other way around; in which case, to "continue or not" is a non-issue. Repeated exceptions in a loop are a symptom of bigger problems that should be solved; not just "handled".
Exceptions are for "exceptions"; not general error handling.
|
|
|
|
|
In catch, continue will automatically work so no need to add the keyword there.
hi
|
|
|
|
|
But it is still a very bad (stupid) thing to do.
|
|
|
|
|
If one does not include the "continue" then execution will continue after the catch-block, not at the start of the loop.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|