What the hell? I’ve been programming since the 70s and nothing has ever stymied me. I’ve written assembler, C, Fortran, VB, etc. I loved structured programming when it came along. When I started working with Windows I had to learn VB and learned about objects, events, etc. The learning curve wasn’t very steep, I could appreciate the usefulness of the new concepts, and I quickly became proficient in it.
Now I have a new project coming up using C# .Net for a Pocket PC device. This’ll be no problem, I thought, I’ve easily conquered everything that’s come before and this’ll be fun and will look good on my resume.
I started out with a simple “Hello World” on a form and I even added a timer to make it blink. Easy stuff! I figured that for a next attempt, I would put a keyboard InputPanel object on a form to allow the user to enter text into a textbox. Suddenly I find myself dealing with event delegates, signatures, eventargs, constructors, destructors, and I don’t know what the hell else. And could the help pages be any more obtuse? I shouldn’t have to spend half a day figuring out how to let the user enter some freakin text! Is there any good reason for all of this complicated, obtuse, confusing overhead other than to make the code more difficult to write, read, and maintain? Honest to God, I would gladly write in assembler in preference to this stuff. I almost think I’d prefer to write in binary!
I know that someone will come along and explain to me why all of it is good and necessary, and they may even be right, but right now I just needed to vent. Am I the only one who feels this way?
Hmmmm… my background is Windows programming, mostly C/C++, with a little VB thrown in for fun. I got a gig doing C# last year and picked it up in about 5 minutes.
I don’t see C++ on your list of languages… that’s the one C# is closest to, perhaps that’s the problem? Either that or the Pocket PC stuff is goofy, I’ve never even seen that so I can’t comment. But from my perspective, C# combined a lot of the ease of VB with the elegance of C++. I like it.
If constructors and destructors are confusing to you, you need to do some catching up.
That came out a lot less pleasant than I meant it. No offense intended.
Anyway, C# is an object-oriented language. If you’ve never dealt with one of those before, there is going to be a pretty steep learning curve. Personally, I’d start with C++, as it’s pretty close to C, and it doesn’t have a lot of the crap that’s associated with C#. But if you don’t have a choice, you might want to look for a book with a title like “Object-Oriented Programming for Managers” to give you a quick introduction.
Davidm I go back to the days of BASIC and COBOL.
Now that I do web programming, I’ve had to learn JavaScript which to me is just like any other language - except any JavaScript manuals, books, etc are written in some cryptic, verbose “high-tech speak”. I have no problem with the languages - it’s the damned books and tutorials that need some serious re-thinking. As time goes on, it seems authors like to get more pompous and obscure in explaining fundamenal concepts. (Things like referring to a message board as a Shared Public Information Deleivery System. :rolleyes: )
This is because, has time goes on, no one in the computer industry is discovering anything new, so they make up grandiose names and acronyms to obscure the fact that all they’re capable of doing is shitting out trivial–and quite often WORSE–variations on the same theme.
(I work in the industry, AND I hate it. 
)
Especially since in C#/.NET, destructors pretty much don’t exist.
Another thing davidm might be having trouble with is he could have a goofy control. By “goofy control” I mean a control that just defies any sort of logic as far as getting the damn thing to work. I’ve encountered this before with the DataGrid control that comes with .NET. Getting that damn thing to do ANYTHING requires a level of coding that defies logic.
To wit: I needed to make the background color of a column in the DataGrid a different color depending on the type of data it showed. Surely, that’s not too weird of a request - identifying data types by color is done in just about every type of publication there is. To do it in that damn DataGrid required subclassing the DataGridStyle object and overloading the Paint event. Why “column color” is not an attribute of the DataGridColumnClass I will never know. I probably wrote close to 500 lines of code to change the color of a column.
The color wasn’t the only thing I had to subclass, either. Seems like about half the things I would consider a standard feature for a control on this fookin’ DataGrid required subclassing and overloading. Is that a problem with the C# language? No, it’s the fault of whoever wrote the piece-of-shit DataGrid control.
Eh, why would you want to do all that? Just put a standard textbox on the form and the user will be able to select it and enter text into it using one of the various input methods. Then you’ll probably want to add a button to do something with the text, or add a TextChanged event which is triggered whenever a character is entered or deleted. It works just the same as a normal .NET forms app, and not much different from VB or most other GUI builders. Or is it that I am misunderstanding you, and you already have the basic textbox working and now you want to do something more complex?
The InputPanel control is not needed for simple text entry, and you probably shouldn’t want to use it in your second trial program already. Delegates can be a bit tricky to wrap your head around even if you’ve already had some exposure to event-driven programming, but you shouldn’t need them for a while.
The manual pages are mainly intended as a reference, not as a study guide. If you’ve never done anything with .NET before, you might want to read a book or get some training first. Given your background, I have no doubt that you’ll figure it all out soon enough, but getting some help in getting through the first couple of days is probably a good idea. Also, you may want to build a couple of ordinary winforms applications first to get familiar with the basic concepts, instead of jumping straight into the Mobile SDK.
Well, .NET does have its drawbacks, but obtuse on-line documentation, a steep learning curve or lots of confusing overhead are not the ones most often named in that regard, is my experience. What tools are you comparing it to? Certainly, when you were doing assembly and FORTRAN, you weren’t building nontrivial GUI applications on your first day using nothing but the on-line documentation that came with the IDE, were you?
Slight correction: you will be using events and delegates for even the most trivial forms app, it’s just that Visual Studio does 99% of the work for you. Just select a control, click the ‘lightning bolt’ icon, choose the event you want to override, and the IDE will magically write the neccesary glue code for you. VB and other GUI builder tools have events as well and they work pretty much the same way, they may just be better hidden.
You seldom need to be mucking around with events and delegates at a lower level than that, at least for your first few toy programs. And by the time you do need to do that, you’ll probably be doing things that would not have been trivial in most other programming environments, either.
Unless, of course, you’re using .NET’s fucking piece of shit craptacular DataGrid object.
C# is just Java with the serial number filed off.
Heh… one thing I have learned from working with the .Net Compact Framework (i.e. for Pocket PC and WinCE), is don’t ever think that a simple task will be “no problem”.
I’ve been working with the .Net CF for close to a year now, and there are still things that grab my goat, and yank real hard. Take for instance, working with “Pocket Access”, for the PPC… I’m not even sure why they call it a database. Calling it a castrated version of a database would still give it too much credit. On the bottom of the list of things that piss me off about ADOCE, is that the UPDATE keyword is not included in the subset of SQL that ADOCE uses. :rolleyes:
I understand that when you’re trying to develop a framework for devices with limited resources, you’re going to have to think about eliminating functionality, and essentially create a workable subset of any given framework… but I emphasize “workable”, since Microsoft apparently missed that part.
IMHO, if you want to see a good implementation of this idea, you should check out the whitepapers on Sun’s CLDC (Connected Limited Device Configuration) and MIDP (Mobile Information Device Profile) specs for J2ME. Of course, this framework is more geared toward devices with more limitations (<1MB memory pool), but the whole general concept was just pulled off much better than the .Net CF, by Microsoft. (Not that I would expect any less from Sun…)
If I could agree with you more, I would probably be invading your personal space.
No way… I mean, C# has Properties, and Java has getters and setters… they’re completely different things… 
LilShieste
…I was going to include this in my earlier reply. oops…
I believe that MS created the .Net CF, to provide the core “functionality” of the .Net framework to Pocket PC, and Windows CE devices. Since these devices typically will be much more restrictive than their PC counterparts (i.e. processing power, memory pool, screen size), some functionality is not really needed, and thus eliminated completely from the CF. One example of this would be something the like MouseHover event; on a PPC, you use a stylus, and the screen can’t really tell if you’re holding the stylus close to the screen, while not touching it. So… why include this in the CF, if it’s just going to be taking up dead space?
The problem comes in when Microsoft starts making poor decisions on what to eliminate from the .Net framework, in creating the CF (you have already experienced some of the consequences of these decisions).
My griping of ADOCE is more just a general griping of poorly done jobs of creating a subset; IMO, this lack of planning ends up costing more than it’s worth. For example: since ADOCE does not support UPDATE, developers have to devise ways of “simulating” an UPDATE statement. One way would be: SELECT all of the data from the old record, and DELETE the old record. Then, INSERT a new record, using the queried updated data. The problem is: while trying to conserve space (I hope someone tells me that there’s another reason…) by eliminating this bit of functionality, I suspect that they have created more overhead for the poor devices.
LilShieste
Yeah, probably. I do like the idea of delegates, though–one unsafe function pointer cast, and you can fuck things up pretty badly.
Programmers who use function pointers in an object-oriented language should be spanked and sent to bed without supper.
And don’t get me started about SysV signal handling…
I don’t see a better way to do event handling in, say, a custom graphics library. What would you recommend?
Simple inheritance?
With virtual functions, that is.
When I say “InputPanel” I’m talking about the little keyboard thing that can be brought up at the bottom of the screen. As far as I can see, you need a keyboard for text input, right? I mentioned delegates because adding the InputPanel causes the IDE to automatically generate code that involves delegates and when I try to compile, their code generates a syntax error. I know that it’s most likely due to something I’ve missed but I probably need an understanding of it to figure out what the problem is. I understand the basic idea that a delegate is a function pointer but the code just looks strange to me. It’s using += and seems to be adding one function pointer to another. 
I don’t have any C+ experience so I’m sure that that’s part of my problem. VB hides most of this stuff and makes it easy (too easy). I have done VB programming for the same device so I’m familiar with the frustrations of CE. For example, the fact that some events never seem to occur when they should. We’re using SQL Server CE which does allow updates so I haven’t run into that problem (thank God).
I have written some classes in VB, one rather large and complex one, in fact. And I’m very familiar with methods and properties. And I do have some basic understanding of the concepts behind inheritance, constructors, destructors, etc. I know that I have to expect a learning curve and I’m used to the obtuseness of Microsoft help pages. I’m certain that I will catch on soon enough. I basically just felt the need to vent. I appreciate all of your responses.
I agree with Metacom (posting #6).
And DavidM, you refer to the obtuseness of Microsoft help pages - that is a vast understatement. Their alleged “help” pages are horrendous.
Just out of curiosity, since I’ve been using JavaScript for 5 years now, what makes it an “object-oriented” language? What is it about Fortran and COBOL that makes them have incredible non-object-oriented characteristics? What brought about this “object-oriented” revolution?