The long-hand version is only meant to show what ?: does, it is not the same thing. The problem here is that if/else is a statement (so it has no value, only a side effect) and a?b:c is an expression (it computes a value).
On top of that, the || operator is a short circuiting operator that obviously (once you know what it does) can not work on bytes.
Furthermore, in C# arithmetic operators on bytes produce ints as result, so even if you fixed the other errors the compiler would complain about the type.
But that's all easy to solve, for example:
- by writing (byte)(IterateLFSR() ? 0xFF : 0xFE)
- by writing
x = 0xFF;
x = 0xFE;
(and then using x, of course)
- or (byte)(IterateLFSR() | 0xFE) if you change IterateLFSR to this:
_LFSR = unchecked((byte)((_LFSR << 1) | (_LFSR >> 7 ^ _LFSR >> 5 ^ _LFSR >> 4 ^ _LFSR >> 1) & 1));
return _LFSR >> 1; // the previous bit is still available, it just moved one place
I moved some stuff around there, but the result is the same (as a bit in an int instead of a bool that has to be converted back to that bit). The other bits in the result should be treated as garbage. Or-ing it with something that has 1 in all the high bits throws them out which is why it isn't a problem in IterateLFSR() | 0xFE.
If you're asking why the code does what it does, that answer can be found in the documentation for whatever chip this is driving.
Some parts of that code look rather strange, you might want to go back to the source (metaphorically speaking, not this source code!) and rewrite the protocol code yourself. It would be a good exercise in 'bit-twidding' in C#. Does this code actually work? It doesn't look like it should in a few places unless the underlying protocol is weird.
First of all you should have a flag field on your users table which determines which user are online. On my databases this field I name it as "logged" with the type of bit and then on the time when the user is logged to the application then this field will be updated to true and on the time when he is loged out then will be false. Since you have this flag on your users table it's very easy to know which users are online.
Do you really need to sort the collection itself or just view it as sorted without changing the underlying collection? If the first, follow the previous answers. If the second, then you can just expose an ICollectionView[^] and bind to that rather than to the root collection.
hi frnds im doing a project and in a face of adding a forum in my project so is there anyone who can help me....with code or ideas regd forum in .net c#.....im new here and wish ur help and support dear friends........
- Please do not use text speech. it's annoying to read. Also use full sentences and try to correct spelling errors before posting. Not everybody is native English, but do give an effort.
- People will not give you code. They will only point you in the right direction if you have a well defined problem. It helps if you explain what you tried or what you searched for yourself. If you do post code, do so with smaller snippets.
- We don't dislike you, but we're not your friends.
- Don't expect people to put time into research and formulating an answer when you can't put time in asking the question.
I built a plugin for a parent application on an x86 OS at work, and came home to try it and it would not work. I got the error code of "0x8007000B" when trying to load the dll which lead me to find out that because dll was set to build to anycpu there is some sort of conflict.
Does anyone have any idea as to how to fix this so that it always works, no matter the CPU architecture?
There is no general solution, applicable to all applications. The fundamental rule is a process must be homogeneous, i.e. consist of all x86 or all x64 code; so e.g. you can't build a plug-in that works for both a 32-bit and a 64-bit native app (say Internet Explorer).
However, if app and plug-in are both managed code, then building for x86 should always work, as each x64 processor and Windows version (at this moment) is able to execute x86 code as well. One caveat: you need all referenced files on your machine, and that may be tricky in some situations.
Remark: Visual Studio Express doesn't let you choose, it generates "AnyCPU" (Google will yield some work-arounds though). Full Visual Studio lets you choose, unfortunately the default is "AnyCPU", which may cause your app to start as a 64-bit process, to later discover some needed native file isn't available for 64-bit (warning: on Win64, 64-bit system code resides in system32, and 32-bit code in systemWow64!).
With some further troubleshooting, I have discovered something interesting. I thought the problem was the plugin dll I had written, but it turns out it was actually a resource dll that was inside of my projects plugin dll. So the hierarchy is this:
I do not have any control over either the Parent Applications code or the resource dll. It looks as if when the Parent application and the plugin I wrote are ran as a 64bit application (on a 64bit OS) the resource dll will not load. Does this sound like a reasonable diagnosis? If so, is there a work around for this situation?
The main code decides on the word size of the process (either directly by being built for 32 or 64bit, or by looking at the OS when managed and "AnyCPU"); everything else must comply to the top-level code.
Hence, if resource.dll is 32-bit, it all must be 32-bit; there is no way around that.