|
1. The lounge is for the CodeProject community to discuss things of interest to the community, and as a place for the whole community to participate. It is, first and foremost, a respectful meeting and discussion area for those wishing to discuss the life of a Software developer.
The #1 rule is: Be respectful of others, of the site, and of the community as a whole.
2. Technical discussions are welcome, but if you need specific programming question answered please use Quick Answers[^], or to discussion your programming problem in depth use the programming forums[^]. We encourage technical discussion, but this is a general discussion forum, not a programming Q&A forum. Posts will be moved or deleted if they fit better elsewhere.
3. No sys-admin, networking, "how do I setup XYZ" questions. For those use the SysAdmin[^] or Hardware and Devices[^] forums.
4. No politics (including enviro-politics[^]), no sex, no religion. This is a community for software development. There are plenty of other sites that are far more appropriate for these discussions.
5. Nothing Not Safe For Work, nothing you would not want your wife/husband, your girlfriend/boyfriend, your mother or your kid sister seeing on your screen.
6. Any personal attacks, any spam, any advertising, any trolling, or any abuse of the rules will result in your account being removed.
7. Not everyone's first language is English. Be understanding.
Please respect the community and respect each other. We are of many cultures so remember that. Don't assume others understand you are joking, don't belittle anyone for taking offense or being thin skinned.
We are a community for software developers. Leave the egos at the door.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
modified 16-Sep-19 9:31am.
|
|
|
|
|
I would recommend my old Elf's keyboard[^]. Steel case, real key switches and lasts at least 42 years long.
But parallel keyboards of that sort don't grow on trees these days and I will need something more modern when I build 'Zwölf', Elf's younger brother. Just yesterday I was asking dumb questions about interfacing USB ports to an 8 bit computer, guess why.
But there is another way to get exactly the keyboard that you want and that lasts forever.
Tear out the encoder and the cable from an old keyboard. Then buy about a pound of cherry keyswitches[^]. Then design and 3D print keycaps and a case for the keyboard[^]. Layout, spacing and finish are entirely up to you.
You will not need a circuit board. The keyswitches snap into square holes in the case, but you will have to wire up the switches in columns and rows on the underside and then also connect the encoder you have salvaged from an old keyboard.
I might have to do a little more, like programming a PIC microcontroller with a suitable interface as keyboard encoder, but that's worth it. That keyboard can last another 42 years.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Good idea, switches are cheap enough.
They call me different but the truth is they're all the same!
JaxCoder.com
|
|
|
|
|
|
Was de-bounce technology common in those days, or was that offered as an upgrade? 
/ravi
|
|
|
|
|
Why not buy a Cherry keyboard?
|
|
|
|
|
I heard they are especially good for cherry-picking with Git 
|
|
|
|
|
I need a replacement for Microsoft's Queue<t> that allows for efficient indexed access to the items therein.
So I made one.
The trouble is, I don't know what to name it.
By default, containers in .NET are implemented on arrays (like mine is) so since .NET 2.0 things like ArrayList have simply become (Implied Array)List<t> - indicating array storage unless otherwise specified or there is no default array storage implementation (like with binary trees). The reason this comes up is because of things like LinkedList<t>
So while I'd name mine ArrayQueue<t> that itself is inconsistent with microsoft's naming conventions post 1.x
Queue<t> itself conflicts but it's what it's currently named. I've made the interface compatible but put it under a different namespace. I'm kind of leaning toward this.
Another option I considered was ListQueue<t> because it provides indexed access, but that doesn't really jibe with microsoft's naming conventions either.
To be honest, I wish Microsoft would have simply exposed the internal method they have in the reference source in order to provide indexed access. Seems silly that they didn't, since queues are ordered by definition, but whatever.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: Queue<t> itself conflicts
Not if you namespace it. 
/ravi
|
|
|
|
|
Yeah I did namespace it. Still, conflicting with Microsoft's class name irks me a little. I think it can get confusing and icky if you reference System.Collections.Generic in your usings, which is really common (and I think by default when you create a new C# file in a VS .net framework project)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
|
'cept it's a list. Collection doesn't guarantee order. List does, and provides indexed access, which my queue does.
I'll consider QueueList, thanks
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
When Microsoft extend something they usually (well quite often) add the suffix Ex. So how about QueueEx ? Does it not show up in Reference Source[^]?
|
|
|
|
|
They do that more in Win32 and COM than .NET
Usually with .NET they just stick new objects under a new namespace and try to name them differently. 
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
How is about _001<t> 
It does not solve my Problem, but it answers my question
|
|
|
|
|
Bob.
Bob<T> myBob = new Bob<T>();
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
|
Oooh, I like that one. I'll definitely consider it. So far it looks like it might be a winner. 
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
That was my first thought as well.
You beat me to it!
|
|
|
|
|
honey the codewitch wrote: I wish Microsoft would have simply exposed the internal method they have in the reference source
Add an extension method and use reflection to call it. 
Oh wait, you said efficient indexing. 
|
|
|
|
|
Yeah, I was gonna say.
Not only that, it's kind of terrible to rely on a non-public method in someone else's code.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
From the top of my head.public static T GetAtIndex(this Queue<T> queue, int index)
{
T obj = default(T);
int count = queue.Count;
for (int i = 0; i < count; i += 1)
{
T temp = queue.Dequeue();
if (i == index)
{
obj = temp;
}
queue.Enqueue(temp);
}
return obj;
}I'm pretty sure that's how Microsoft intended it 
It's lightning fast if you have only a few items and you don't do it too often
Or you could do whatever you're doing an name it IndexedQueue, like Greg also suggested.
|
|
|
|
|
That reorders the queue. I can't have my indexing have side effects. If I didn't have to worry about that your solution would be a decent one.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
|
I misread your code. I thought you were just enumerating until you found the item.
Anyway, I'm not sure that would be faster. See based on what I know from the reference source, there's no reallocations taking place with your technique. It's just setting array elements and incrementing some integers.
Reflection can be kinda nasty. I'd have to profile. It definitely depends on the number of items in the queue as well, but for what I'm currently using it for, it shouldn't be more than a half dozen to a couple dozen items.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
