|
Use classes instead of structs and make the default constructor private. By the way, when I have to use P/Invoke I always try to maintain the things as simple as possible and, in my opinion, I think you are looping the loops here. Since the C function receives an array, I would have used IntPtr type for the parameter, so I would be able to pass any array with the help of Marshal class.
|
|
|
|
|
I'm trying to see if I can check if the credentials the user provides will be able to login to a remote machine. Right now I'm using NetUseAdd to add an IPC connection but this will give error 1219 if the credentials are cached.
Any ideas?
|
|
|
|
|
Just curious, but I just saw this code and I was wondering what the difference was. The code I saw was (basically):
FontStyle style = someFont.Style;
style |= FontStyle.Italic;
How is that any different than:
FontStyle style = someFont.Style;
style = FontStyle.Italic;
|
|
|
|
|
The pipe operator (|) is a binary OR... So:
style |= FontStyle.Italic
...is equivalent to...
style = style | FontStyle.Italic
If style is initially zero, this is the same as a straight assignment (0 | x == x), but if you already have an existing value in there (Maybe 'Bold' is another value), the |= operator would make it Italic AND Bold, while an assignment would replace Bold with Italic.
(This only makes sense with flags-type enumerations, of course)
|
|
|
|
|
Ah...thanks...makes sense!
|
|
|
|
|
Ian Shlasko wrote: (This only makes sense with flags-type enumerations, of course)
That is not necessarily true.
|
|
|
|
|
Well if it's a regular enumeration (Consecutive integers), you're generally not going to be adding/removing values via bitwise operations... Sure, there could be exceptions, but I can't think of any off-hand.
|
|
|
|
|
That does make sense, depending on your meaning. If you mean this:
public enum MyEnum
{
x = 0,
a = 1,
b = 2,
c = 4,
d = 8
}
Then yeah, it works perfectly fine. If you meant this:
[Flags]
public enum MyEnum
{
x = 0,
a = 1,
b = 2,
c = 4,
d = 8
}
The "Flags" attribute is not actually necessary for the bitwise operations to be successful. It just adds intellisense and changes the behavior of ToString (e.g., it may output "a, d" rather than "9").
|
|
|
|
|
Correct. And there are also cases like:
public enum Side
{
None = 0 ,
Left = 1 ,
Right = 2 ,
Both = 3
}
where all the bases are covered and you gain nothing by using Flags.
|
|
|
|
|
I know... I meant "flags-type" as a way of describing them (Wasn't sure if he was familiar with the term "bitmask")... The attribute is just gravy.
|
|
|
|
|
I didn't know that. Or if I did, I forgot. 
|
|
|
|
|
|
In C/C++/Java/C# |= is to || or | what += is to +.
So it is a bit-wise or a logical assign-OR, depending on the operands' types.
|
|
|
|
|
Haha, sorry Luc, great answer, but I have to tell you how I read this:
Luc Pattyn wrote: |= is to || or | what += is to +
"or equals is to or or or what plus equals is to plus" 
|
|
|
|
|
William Winner wrote: FontStyle style = someFont.Style;
style = FontStyle.Italic;
This is not equivalent to the first version, which effectively could be written as
FontStyle style = someFont.Style | FontStyle.Italic; This means that you are doing a logicalbitwise OR on the style, whereas your example here overwrites the style.
[Edit]Thanks for pointing out the error in this statement goes to Luc.
I'm not a stalker, I just know things. Oh by the way, you're out of milk. Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Onyx
modified on Monday, January 3, 2011 3:26 PM
|
|
|
|
|
as FontStyle is an enum, hence a numeric, it would be a bit-wise OR, not a logical one.
|
|
|
|
|
Doh. I completely forgot it was an enum. Slaps side of head.
|
|
|
|
|
Don't feel bad... Luc did too... He had fixed it by the time I clicked Reply on his post to point it out
|
|
|
|
|
With two small differences: I noticed the mistake and fixed it; and I didn't slap Pete's head.
|
|
|
|
|
|
Hi Guys, I'm facing a very weird problem, I'm referencing a third party dll in a windows service I'm developing.
When I add the reference, then include it in the using list and work with the dll everything is fine, intelesense picks up all the methods in the dll etc, but the moment that I build my project it gives exceptions on the dll, intelesense no longer recognizes it or the methods I used.
The excpetion I receive after the build is.. The type or namespace name 'XXX' could not be found (are you missing a using directive or an assembly reference?)
Any ideas or help would really be appreciated.
Thanks
No matter how long he who laughs last laughs, he who laughs first has a head start!
|
|
|
|
|
I'm not sure if this will solve the problem, but one thing to check is that the dll gets copied to the output directory if it isn't in the GAC
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
It does not appear that the dll is being copied to the bin directory on the build. You can have a look at my message below for more detailed explanation of the setup.
Thanks for the reply.
No matter how long he who laughs last laughs, he who laughs first has a head start!
|
|
|
|
|
In my experience the only way that can happen is if the dll is getting overwritten.
Since it is a 3rd party dll that would suggest that you are copying a new version in. Or even building to the wrong name perhaps (your library has the same name.)
|
|
|
|
|
Thanks for the reply.
I should clarify that by third party I mean that; the dll is a class library (developed by different team) residing under the same main solution as what the windows service (being developed by myself) is. So when I reference it I add the reference to the class library project under the solution and not the compiled dll as such, with the understanding that in doing so that when the solution builds that class library builds and the dll is supposed to be built to the bin directory of my service, which is currently not happening and I suspect that to be the problem.
But the strange thing is that if I just add the reference to the library, intelesense picks up the namespace of the library, I'm able to instantiate methods under the library etc, but as soon as I run that first build it no longer recognizes the namespace or any of the method instantiation.
I'll try changing the reference from the project to the compiled dll directly and hopefully that will help.
Thanks for the help.
No matter how long he who laughs last laughs, he who laughs first has a head start!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
