This has been driving me nutty for years in C#...

...but I finally figured out how to prevent the damn Visual Studio IDE from inserting asterisks into EVERY DAMN LINE of comments I put in a C# file (guess I should have Googled this.)

Simply disable:

Text Editor > C# > Advanced > Generate XML documentation comments for ///

I know, bizarrely unobvious considering there are a myriad of settings for comment templates where you basically specify 'do not do anything when I create a comment' which are blithely ignored by this #$)(#@$* setting.

I hope this makes someone else's day better like it did mine :).

I guess this is where I lean...

My Political Views
I am a center-left moderate social libertarian
Left: 1.1, Libertarian: 3.06

Political Spectrum Quiz

If you need to see the MSJVM console in IE7...

...then there are two things you need to do (or you may be able to skip step #1 and proceed directly to step #2 depending upon your current settings.)

(1)Go to the menu bar (enable it if you've hidden it) and choose Tools|Internet Options|Advanced, scroll down to "Microsoft VM" and enable "Java console enabled". You need to close and re-open your browser after this.

(2)When running an applet, go to the menu bar and choose View|Java Console (it should be the item right after 'Full Screen' on the menu.)

Hope this helps people testing applets on the MSJVM like I am currently.

A little bit of magic from Fernando Torres...

Enjoy! (Benayoun's pass wasn't too shabby either)

If "Open in New Window" is not working...

...for you or "Open in New Tab" with IE8, it turns out that there's a strong likelyhood that (for some unknown reason) the installation forgot to register a particular component so:

(1)Open a command prompt as Administrator
(2)Type 'regsvr32 actxprxy.dll' and press Enter.

You should get a small dialog popping up telling you that the DLL was registered properly.

Now try IE8 again.

I cannot fathom how Micro$oft has not found and eliminated this problem in IE8. It has existed since the early betas. Ridiculous.

Annoying issue with Eclipse...

...for some reason you can't really export/import your preferences between installations of Ganymede (a version of the Eclipse IDE), and I've been using it on several machines lately and having to set all kinds of crap up to be the same manually. This wouldn't be much of an issue except that the options are spread out rather willy-nilly in the application (although that is likely a residual of the very plugin based architecture.) So, I finally tracked down where the most annoying options for me to setup are located - syntax coloring for Java (your annoyances will likely differ :).)

After looking all over the place for them, I finally found them stored with each work space, not as settings for the application itself - weird (to me...)

Anyhow, for syntax coloring there are two files you want to copy into your workspace's folder in order to equate them to those in another folder, the folder in question being:

<Your Workspace>\.metadata\.plugins\org.eclipse.core.runtime\.settings\

org.eclipse.jdt.ui.prefs
org.eclipse.ui.editors.prefs

Update to services in Android...

...it turns out that what you really should do, if your code is in separate projects, is to declare a global (I presume) service moniker like this (in your service's manifest):

<action android:name="com.android.TestService.TEST_SERVICE" />

Then, change the method by which you call startService to call like this:

startService( new Intent( "com.android.TestService.TEST_SERVICE" ) );

NOTE: The argument is a string, which is the key. (Don't forget to change your invocation to stopService if you call that as well.)

Google might want to think about software less for tinkerers and more for real software engineers who will need to organize their code and look for opportunities to re-use, especially regarding services, and mention in their documentation that they recommend you add this naming schema to your service manifests for good reason. I'm just glad I noticed it in the remote services sample code.

If you're having a hard time with services under Android...

...I can feel your pain. The SDK documentation is good from a referential point of view, but focuses primarily (as you would expect) on the more superficial aspects of the system. Personally, I'm interested in services, IPC mechanisms, and networking so that means I get to read a bunch of API docs and peruse some of the samples.

Now the Android SDK samples aren't bad; however, they are limited. Let's say you're going to write a GUI application (termed for some reason by Google as an 'Activity') and you're going to write a service (as in daemon/service.) Google gives you an example of doing so, but for some reason decided to include all the manifest data for ALL THE SAMPLES into the same manifest file and as one big project (which has implications under Eclipse - which is presumably the development environment you're working in unless you're a sadist and you probably enjoy the pain I'm describing anyhow...)

Well, real projects for useful applications do NOT clump everything together in a single manifest, and they do NOT clump all the source code into the same project. Separating the two is not difficult; HOWEVER, Google's documentation and everything I could find on the 'net regarding service declarations in application manifests neglects to mention what you need to do when yo uhave one project that will be a client of the service and the other project being the service in question. Now, maybe I'm an idiot, but I spent several hours trying to understand why my client application could not successfully call 'startService' on a perfectly named, installed, and runnable service that was on the emulator. The log kept reporting that the component could not be found (while explicitly listing the component correctly which means it had exactly the right package name.) After beating my head for hours, I finally wised up to the fact that I was making an enormous assumption.

I was ASSuming that Google wasn't doing something funny with the service binding mechanism and that because it used a standard Java packaging nomenclature, surely that meant that my client application could call 'startService' and have the OS identify the package correctly. Boy was I wrong.

Apparently, the 'multi-project' trick with a service is that you must declare the service in the manifest of every client application that you will have use the service - even though the declaration is just supposed to be in the service project's manifest according to the documentation (and you cannot tell from the samples because they're all glommed together.)

So, before I forget this, and so I can google my own frustration when I do forget this:

In your client manifest XML you need to add this inside :

<service name="com.MyPackages.MyService.MyServiceClass">

Please note the full package name usage, which is HIGHLY recommended in case you move projects around or rename things. BTW, if your service is to run in its own process, add
android:process=":remote" to your service tag, otherwise it runs locally which I don't understand the purpose of really.

So, to sum up. If you create a service, you'll have a manifest for that project with a service entry in it, as one would expect. If you create a client that will make use of this service, you'll have to add, oddly, a service entry in the client's manifest as well.

I don't know if this is a bug or not, but it was certainly unclear to me. Hope this helps somebody.