Coin organizer, a small software project

bullionbox · 04-14-2009, 05:51 PM

Hi.

I've recently started collecting coins (mainly swedish coins) and decided to write a program that organizes coins i an xml database. I started this "project" for fun and I'm developing it as a hobby in my spare time (I'm a student).

I'd like to share this program with other more knowledgable collectors in order to get some input on the program (look & feel ,required features, bugs etc).

The program is written i C# (.NET) and requires the .NET framework (comes with windows vista). The reason I chose .net was that it's much faster to implement features than in c++. The con is that you need the .net framework installed and the application can be sluggish on very slow computers.

The program is freeware and is primarily made for fun. Feel free to post any critique/suggestions here.

Please excuse my english since I'm from Sweden.

Just Carl · 04-14-2009, 06:35 PM

Many such programs are available. Not sure where your at if Microsoft Excel or Access is available but here I think the majority of people use those for that purpose. True some do try some of those other programs, but I truely suspect the mamority of people use the Microsoft programs.
One really nice advantage to them is the massive amount of info available in book stores, at places where people work, on the internet, etc.
And you can use your info almost anywhere.

mrbrklyn · 04-14-2009, 09:11 PM

I'd rather die that use C# .. I removed all of gnone from my desktop because of mono

Ruben

bullionbox · 04-15-2009, 08:01 AM

Quote:

Originally Posted by mrbrklyn

I'd rather die that use C# .. I removed all of gnone from my desktop because of mono

Ruben

That doesn't make any sense to me..

bullionbox · 04-15-2009, 08:02 AM

Quote:

Originally Posted by Just Carl

Many such programs are available. Not sure where your at if Microsoft Excel or Access is available but here I think the majority of people use those for that purpose. True some do try some of those other programs, but I truely suspect the mamority of people use the Microsoft programs.
One really nice advantage to them is the massive amount of info available in book stores, at places where people work, on the internet, etc.
And you can use your info almost anywhere.

True.

asciibaron · 04-15-2009, 11:51 AM

i'm playing around with the program - i like it - i have no use for the pictures part, i own the coins and can look at them whenever i want

the only issue i have is that the Coin Category should be dependent on the country. Sweden does not have a Penny, so why is that an option?

if the Coin Category would be country based, it would make this program a valuable tool for me. having a drop down of 50 denominations is overwhelming and impractical.

there should also be a mint field - i have 3 dimes in my hand, one from Denver, one from Philly, and one from San Fran...

also, editing of a record does not work within the program.

get these sorted and i'll use it.

any chance you can share the source code with me?

-Steve

bullionbox · 04-15-2009, 06:19 PM

Quote:

Originally Posted by asciibaron

i'm playing around with the program - i like it - i have no use for the pictures part, i own the coins and can look at them whenever i want

the only issue i have is that the Coin Category should be dependent on the country. Sweden does not have a Penny, so why is that an option?

if the Coin Category would be country based, it would make this program a valuable tool for me. having a drop down of 50 denominations is overwhelming and impractical.

there should also be a mint field - i have 3 dimes in my hand, one from Denver, one from Philly, and one from San Fran...

also, editing of a record does not work within the program.

get these sorted and i'll use it.

any chance you can share the source code with me?

-Steve

Thanks for the input. I'll fix the issues.

I'm planning on adding some sort of compression of the coin xml database. Lot's of coins -> plenty of megabytes.

I'll share the source when the program is more complete.

mrbrklyn · 04-15-2009, 11:55 PM

Quote:

Originally Posted by bullionbox

That doesn't make any sense to me..

It should

mrbrklyn · 04-16-2009, 12:03 AM

Quote:

Why Mono is Currently An Unacceptable Risk (Score:5, Insightful)
by Anonymous Coward on Saturday October 08 2005, @05:19AM (#13745664)
Argument In Brief

1. Microsoft's C#/CLI licensing people, at high levels, are aware of us.
2. Microsoft can choose to do damaging things in the current C#/CLI licensing ambiguity.
3. Microsoft considers the free software / Linux community to be a major competitive threat
4. Microsoft does not "compete" gently
5. A + B + C + D = ?

The word pile amassed below defends points (1) and, in particular, (2). I take points (3) and (4) as given. I leave point (5) an exercise for the reader. ;-)

Stupid Disclaimer

Since I'm not a lawyer, I don't know if these disclaimers are important. But given the nature of the topic, I'll play it safe and write one. I'm not a lawyer, and this ain't legal advice, its just a dump my current thinking on an issue. It does not represent my employer's opinion. It may represent my cat's opinion, but only on the second tuesday of summer months.
Restatement of the Issue

Miguel has repeatedly stated that the patents necessary to implement the standards ECMA-334 (C#) and ECMA-335 (CLI) are available from Microsoft "RAND + Royalty Free". This seems like an effective open patent grant and encouraged me initially that we could do Mono. I really like Mono. Its terrific technically, and I'd love to be able to use it. But two problems upon further consideration the past couple months:

1. I've not seen an official statement by Microsoft that will let me trust the royalty free assertion. I think we are remiss if we do not assume Microsoft is looking for ways to, quite frankly, screw us. So unless there is a statement from Microsoft that they will have to stick to in a court, I feel (at the very least) uncomfortable.
2. "RAND + royalty free", can still seriously screw Free Software. I think this is more important than the first point. Even with RAND + royalty free you still have to execute a license agreement with Microsoft, and license agreements can stipulate things that are RAND from a corporation perspective but still screw over Free Software. Also, there is evidence that key Microsoft people are already aware of (or planned?) incompatibilities between the licensing scheme for C#/CLI and, at least, the GPL. The eye of Sauron is upon us. RAND + royalty free is very different from a patent grant.

In short, we are in an adversarial situation. Microsoft does not want us to succeed. Thus we cannot trust Microsoft, even if we'd like to, and must consider Mono based upon the question "What is the worst thing MS can reasonably do?". We can only trust Mono if we are convinced Microsoft doesn't have weasel room. The current situation appears, to me, to have lots of weasel room. The technical merits of Mono are basically irrelevant if its a trojan horse in the long term.
The Horror Story

So here's the obligatory horror story based upon what I see as our current course. Actually, I don't think this is taken to extremes at all. The GNOME actions look to me like the path we are currently on, and the Microsoft actions are not out of character, and look legally tenable based on what I know today. Microsoft can choose to not exercise these actions, but they will have the possibility (and will be more likely to the more successful the Linux desktop is).

* Act 1 - Novell hackers continue to push Mono. Novell hackers code most new independent programs/functionality in Mono and gradually start writing extensions to software like Evolution in Mono. Evolution's core continues to remain Mono free, but if you want features X, Y, and Z you have to use Mono. A few GNOME hackers write apps in Mono, some as toys, and perhaps a couple more serious. Red Hat hackers complain. Some try to weakly push Java and some stick with working in C & Python. Sun makes noise, and does their own thing, starts some wacky projects, tries to push Java with OpenOffice.org, and
Read the rest of this comment...

Commentary

mrbrklyn · 04-16-2009, 12:05 AM

More commentary

Quote:

C# Sucks S***

July 07, 2004 22:03:11 EDT

"Simple things should be simple. Complex things should be possible". It could be slightly misquoted (I'm going from memory), but I like that quote (From Alan Kay?). I'm currently going through a headache of magnificent proportions, because I have finally reached the point where I can do some basic coding in Smalltalk, and its made me realise just how ****ing poor C# really is.

The Project: The HL7 Parser part of an HL7 Compliant TCP/IP Server.

The Problem: Refactoring a Segment class so subclasses can implement specific behavior (Right now one Segment class with boolean conditionals, its only OO in the sense that is wrapped in a class)

The Solution: Create a static method on the abstract base class. Parses the first 3 characters and gets an instance of the correct subclass.

Sounds easy doesn't it. So I attacked it like so.. Create a static dictionary, use reflection to get all subclasses of Segment, add each to the dictionary, using their specific 3 character segment code as the key, and a Type as the value... This is where it becomes painful. Painful because the smalltalk version is so ****ing simple.

subclassesBySegment isNil
ifTrue: [ subclassesBySegment := IdentityDictionary new.
self subclasses do: [ :aClass | subclassesBySegment at:
aClass segmentCode put: aClass ]].

So now, I have a string of text, I can read in the first 3 characters (aStream upTo: $|) | is the segment separator, and go to my subclassesBySegment dictionary and pull out the class and create it:

segment := (subclassesBySegment at: #MSH) new.

Simplified (It would normally be read from a stream, sent to dictionary, and probably call at:ifAbsent just in case, to create an instance of a GenericSegment or something... ANYWAYS)

Now I tried to do the same thing in C#. It is just a ****ing nightmare.

IDictionary map = new Hashtable();
Type type = typeof(Segment);

Thats as far as I got, because guess what I have to do next? Go through every ****ing type in the system, checking t.IsSubclassOf(type), and if its true, add it to the dictionary...

But thats not all.. See, the Smalltalk version also allows me to just call segmentCode on a subclass, thats a dynamic language for you. Not so in C#. Because Type does not know what the **** the segmentCode method is. So now I have to go into reflection mode:

MethodInfo m = t.GetMethod("segmentCode", BindingFlags.Static);
String key = (String) m.Invoke(t, new object[0]);
map.Add(key, t);

Ok, so now I have done that.. Remember the smalltalk code to pull an instance of an MSH segment out? segment := (subclassesBySegment at: #MSH) new. Great! Lets look at C#: Segment segment = (Segment) Activator.CreateInstance((Type)map"MSH");

Yes, I could have changed it so instead of storing the Type, I stored the ConstructorInfo instead, but thats even worse. I won't even go into that.

Its just ****ed. Trying to create code that reflects on itself and generators tables or whatever at runtime is about 100 times harder than it needs to be. All in the name of compile time safety. I'll take my chances with the dynamic code I think. In my dreams of course, because people at work don't know what the **** Smalltalk is. So the only way I get to use it is as a form of torture on myself... "Oh Sean, you could be finished by now. Instead you've got the ****ing .NET Framework Documentation open and your trying to work out how to do what you need to do... You could be finished by now. HAHAHHAHAHAHAHAH()@!#^(*&#$^@(Y@EOI@#"

Do you know what else I hate? the static keyword. The way Smalltalk class methods are design is brilliant... You know you can actually define a contract on class (static) methods as well? C# just ****s off an error at you specifying interfaces can not contain static methods. Static methods can not be overridden, and so on and so forth.
Comments

mrbrklyn · 04-16-2009, 12:08 AM

more commentary

Quote:

New Feature: C# Sucks
January 21st, 2009
Goto comments Leave a comment

I’ve recently been dragged kicking and screaming into the world of ASP.Net. Our managers have decided to migrate from a LAMP environment to a Microsoft environment. They tried this once already and failed miserably, but maybe the second time around will actually work. Personally, I think they’re glossing over the actual resources necessary to overhaul and migrate our entire setup, but that’s beside the point.

I’ve actually worked with ASP.Net before, using Visual Basic (about two years ago, and for a period of maybe two months). I liked the ideas behind the ASP.Net framework, but VB just felt like a toy language to me. I think that can probably be chalked up to learning QBasic as a kid — an experience that surely traumatized me for life.

Fortunately (or unfortunately, as the case may be), the packages we’re looking at buying are largely based on C#, so we’ve decided to focus on that as our language of choice. I was actually really excited to learn C#. It seemed like it would address a lot of the things that annoyed me with PHP, and it’d be a much more enjoyable way to transition into the world of ASP.Net.

I may have been wrong about that.

As I learn the language, I’m running across some things that strike me as ridiculous, excessive, confusing, or just plain annoying. Taking inspiration from jwz’s whining about Java, I’m going to write down my complaints about the language as I learn it.

Maybe someone can explain to me why these things don’t actually suck, or perhaps they can show me how to do things in a less suck-filled manner. But mostly I’m just happy to have an excuse to ***** and moan about something.

asciibaron · 04-16-2009, 02:24 PM

so you don't like programming in C# - what does that have to do with this person's product? seriously, grow up.

mrbrklyn · 04-16-2009, 08:36 PM

Quote:

Originally Posted by asciibaron

so you don't like programming in C# - what does that have to do with this person's product? seriously, grow up.

Well, for one this, flame not withstanding, XMK is not a database, its an SGML programming dialect and if he used more sensible tools he would have more portability, fewer bugs and a faster runtime environment...

asciibaron · 04-17-2009, 10:26 AM

Quote:

Originally Posted by mrbrklyn

Well, for one this, flame not withstanding, XMK is not a database, its an SGML programming dialect and if he used more sensible tools he would have more portability, fewer bugs and a faster runtime environment...

your preferred programming matrix matters how with regard to the OP's program? i like to program in Ruby and PERL, so you all suck? seriously, grow up.