Erik Porter's Blog

Testing Windows Services

To help a fellow blogger and hopefully other people who read that thread, I posted 4 simple 1 liner bat files to Install, Uninstall, Start & Stop Windows Services that you have created.  Just a handy reference!  :)

Not, simply creating a Windows Service in .NET, then running those scripts won't work.  You must also add a System.Configuration.Install.Installer to your project.

Along these lines though, I will make one suggestion.  When creating a Windows Service, VS.NET really doesn't provide any nice way to test the service, so I would suggest just keeping your code for your service in a Class or a WindowsForm to do all of your testing.  Once you've got it working how you'd like, then turn it into a WindowsService and install it for final testing.

WindowsForms Designer stuff (yet again)

I'm still sitting around working on my control and found another cool service you can access from your designer.  It's the ISelectionService.

What this will do for you is give you access to the item(s) in the current designer that are selected, whether it be your form, a component in the component tray or a few buttons on your form.

I recently needed this so that I could hide a DesignerVerb (i.e. a menu item when you right mouse click on anything in the designer) to only show up only when controls on the parent form were selected.  So in comes ISelectionService to the rescue providing me with a SelectionChanged Event to grab onto and make the appropriate changes to my DesignerVerb (showing it or not showing it).  Here's a little code on how to set up the EventHandler and then displaying how many items are currently selected in the designer.

Public Overrides Sub Initialize(ByVal component As System.ComponentModel.IComponent)
     MyBase.Initialize(component)

     SService = DirectCast(MyBase.GetService(GetType(ISelectionService)), ISelectionService)

     AddHandler SService.SelectionChanged, AddressOf Parent_SelectionChanged
End Sub

Again, I'll be posting this control (and all its code) when it's completed, but I'm just working out a few kinks right now.  For any of you curious as to what this control is:  It's a ControlArray Component with full design time support.  All you ex-VB6'ers out there know what I'm talking about!  ;)  I think this will be a helpful component to all and should be a good learning tool too, since all the source will be included!

Btw, do we have any designer serialization experts in here?  Anyone know how to force the designer to serialize a property?

BlogShares? huh?

Just read Rob's entry.

What the heck is this?

I'm still a blog newbie!

Need to know when a Component is Renamed?

Today I ran into a problem.  The Name Property of a Component (or almost anything else for that matter) is one of those "magic" Properties that doesn't really exist because you created it.  It just magically shows up thanks to .NET.  Well, earlier I was working on a Designer for a Component I'm working on and I needed to know when the Name Property changed (so the Designer could do a couple things).

I tried creating my own Name Property and having it Shadow the other one.  No Go!  I tried deleting it in the PostFilterProperties Event of my Designer.  No Go!  (it actually deleted my new Name Property  ;))

After searching and searching and searching I stubled accross the IComponentChangeService Interface and found a ComponentRenamed Event.  Gave it a try and it worked!  So here's a snippet of code for anyone wanting to do the same thing.

Data Trick

Reading Julie's post, I remembered a little trick and thought I'd share.  Some people might not call this a trick, but I do, because I'd never seen it in the documentation and when I heard about it, thought it was the coolest thing, so I'll share so that hopefully someone else will think it's cool too  ;)

Create a stored procedure (or just set the CommandText seperated by semi-colons) with 2 or more select statements in it.  Set the SelectCommand of your DataAdapter to that StoredProcedure and call the Fill on your DataAdapter.  If you'd like, you can also give a name to the DataTables.  The fun is that you now have more than one DataTable, but only one hit to your Database.  Something like as follows should work!  :)

WindowsForms Designers

Just wanted to plop a quick note to say that Mike Harsh was totally right (as usual)!  WindowsForms Design-time Support is cool!  *thumbsup*  I started in on creating design support for a new WindowsForms Control and am having a blast!  It was a little difficult at first to pick up, but after playing with it for a while and reading articles like this and this, it's all starting to come together in my head.

Adding on Designers to your controls makes them really cool and is a lot of fun!  I've only been doing it now for....oh...less than 24 hours, so I'm not expert, but I'd really recommend checking it out!  Great stuff!  :)

P.S. I will be posting this control I'm working on, on the WindowsForms.NET site soon, so watch for it (especially if you used to be big on VB6  ;))

WebService Usage

I saw Julie's post that took me to Alex's post and I really like this subject.  However, I don't totally agree.

I definitely agree that WebServices are another layer in a multi-layer architecture.  What I don't totally agree with is that there should be no logic in a WebService.  That it should only act as an "interface" layer.  I think in a perfect world, where everybody follows best practices and has all the time they need to do projects, this would be the way to go.  A lot of companies have to weigh "the best way to do something" vs. "the fastest and most cost effective way to do something".  A lot, I would guess, decide that if the business logic is small enough and will never be reused, that it would be better to just throw it in the WebService.  The more OOP-like you make an application, the easier it is to update in the future.  It also goes the other way though, and can make updating more tedious.

The last project I worked on (that's not quite done yet actually) had about 1500 lines of code in it.  Basically though, all the logic in the WebService is really just to "shape" the data that comes from my DAL.  Should I move all that shaping code into another Assembly or even just another class?  Maybe.  If I don't, am I screwing myself over in the future?  Not really.

I just think that there's no difference in programming practice between say WebForms, WebServices & WindowsForms (besides the fact that WebServices don't have UI).  It's a "best practice" to not have any business logic in your UI (or in your WebService, stated by Alex), but does everyone follow that?  Not at all.  Again, I believe the reason being, simply because of time and weighing the benefits.

That said, I agree with Alex, that business logic should be outside of your "layer interface".  I don't think, however, that if you don't do it that way, you should be looked at as someone who doesn't know what they're doing.  Situations vary.

VB.NET vs. C#

Been seeing a lot of posts about the subject...as old as it is, I must comment!  :P

I definitely agree with the original poster!  Pick whatever you're most comfortable with.  I've used both VB.NET and C#, but I still always sway towards VB.NET, simply because I find it much easier to read (and the VS.NET IDE aids me in getting things done faster in VB.NET than C#).

Personally, I think anyone that says either is "better" than the other is just being silly.  That, or is super hardcore and needs to do those few little things that VB.NET doesn't have in it!  ;)  The Framework is really cool part of .NET.  The languages are just there to help you do your job with the Framework in the best way possible for you.

Old Man Back in Action

I took a couple days off for my birthday.  I don't feel any older, but I am 24 now...wowie!  Ok, that's not very old!  ;)  I'm a huge Star Trek Deep Space Nine fan, so for my birthday I got the entire first season on DVD.  Lovin' it!  Quite honestly, I'm not really a Star Trek fan, but this series is just awesome!  (y)  However, I'm not going to have to collect all seven seasons as they come out through this year!  :-\

Now, onto the beef!  Duncan recently posted about a few things related to his Coding4Fun column (great stuff, btw).  One part in particular sparked my interest, when he mentioned the new thing he's working on.  That being, displaying what song you're listening to in your Messenger username.  I actually did this a long time ago, but in a lot less cool way than Duncan would be doing.  One of the first forums I ever got into was We're Here Forums, which currently is working on getting back online after a long, long break.  This was the first forum that I used the name HumanCompiler.  In my signature, I had a Macromedia Flash file that showed my username and next to it displayed the current song I was listening to on my computer.  At the time, I accomplished it by using some API (don't remember anymore, nore do i care to  ;)) in VB6 and an app that sat in my taskbar and ran through all the processes running on my machine and found MusicMatch, then grabbed the main form's title and stripped out the name of the song, then posted it to an ASP page and saved it in a text file every minute or so.  People seemed to think it was pretty neato.  I thought it was the coolest thing.

Then, at PDC 2001, I attended a session about .NET My Services (notice how the link actually takes you to J# stuff  :().  I was in love immediately.  It was the coolest and most "future changing" stuff I'd ever seen.  Now, that was the programmer in me lusting for technology and cool stuff!  I cried myself to sleep a few nights after .NET My Services was "canned" (put back on the shelf for "reorganization").  It was inevitable though and everyone knew it.  I'm extremely curious what the future holds in this area for Microsoft (haven't heard anything in a long time about it).

Anywho, so I got to thinking...why don't I just make my own services for myself to run?  At least I'll get some benefit out of it.  *thinks to myself*  I wonder if other people would be willing to trust some of their data on my server?  I wonder if people would be willing to pay?  I wonder if it would be as lost of a cause as it was for Microsoft.  Should I just write some services and hand them out for free?  Would that make things worse than better?

The programmer in me said, screw it, just start writing for fun.  I'll probably learn some stuff along the way, how can I lose?  So I started with a couple ideas.  One is a web service that saves and retrieves your favorites.  You install an NT Service that simply sits on your computer and watches the file system for any user that has subscribed on that computer and sends any changes to the web service to update their account.  Anytime they jump onto a new computer (work PC, laptop, whatever), they could install the same service and it would put any differences from their account on the web service to the new computer.  After that, anytime any changes are made to any favorites on any of their computers, they'd automatically be updated everytime they login.

My other idea was to use the .NET My Lists idea.  It was one of many free services that was going to be offered by .NET My Services.  Even though this was the simplest idea, it was the first one most people would use (at least I think so anyway).  It's basically a list and that's it.  Any sort of list you'd like.  Grocery list...To Do list...whatever, but you'd be able to access it from wherever you were (PC, Cell Phone, PDA, Tablet, etc).  This one would be pretty easy to implement (except for Passport...I have no clue about that).

I never even started the list idea, but I got almost done with the favorites services, before I had to stop working on it and move on to a project that actually paid.

I guess what I'm really curious about is whether or not this sort of thing can/will work in the future.  Personally, I think stuff like .NET My Services has the potential to be life changing.  I mean can you imagine your PC and/or your XBox telling others on your list what game you're in the middle of playing?  Oh wait...XBox already did that!  ;)  And how cool is it?  Very!  (y)  So why not do more of that?  Would this stuff be worth selling?  Would people actually participate?  Is there money to be made?  Is there no money to be made?

Maybe I'm the only one interested in the subject, but I find it extremely facinating and would love to see other blog entries about subjects like this.

Time to stop typing and go to bed!  :-|

btw, is Bill G ever going to have time to start blogging?  Wouldn't that be cool?  ;)

The Future (Part 1 of many)

Just got done reading DonXML's latest entry and I've got to say that overall, I agree.  Personally, every time I create a new ASPX and it's the first one in the project, I immediately change it from Grid to Flow layout and I use tables.  I'm guessing though that most of my reasons for doing so are because I just don't understand all the possibilities.  WindowsForms uses a grid layout, why shouldn't I do the same thing in WebForms?

However, that got me thinking again (it's something I think about a lot): why should I use a web browser at all?  Web browsers are clunky!  Web browsers make it extremely hard to make a really good UI, with out tons of tricks (that are very hard to manage)!  The other big problem with them is that all layers of an application are processed on the server (except the actual rendering of the UI, but compared to the rest of the processing, that's the easy part).

So again, why should I continue to use the web browser.  The current answer is simple: Distribution of .NET applications still isn't easy enough.  People have to have the Framework installed to use it and setting up security for "streaming apps" is still a royal pain.

I believe Microsoft is definitely headed in the right direction though.  Imagine a world where your applications were no longer limited by what you could do.  A place where servers, act as Data and Business Logic warehouses.  A place where all data and business processing is done on the client, not the server and in this "not so far off future", the client software is updated automatically, with no (or optional) user intervention.  Sounds like the web browser on steroids, huh?  True, except that the web browser will not be needed anymore.

Web browsers are used so commonly today, because they are the cheapest method of deployment for business logic and data, hands down.  In the future, I personally believe, this thought process will be reconsidered.

The Death of the Browser article by Billy Hollis is starting to get pretty old, but it still has a lot of good points.  Check it out.

Need help on getting your WindowsForms application distributed on the web?  Check out the Deployment and Controls in IE section of the WindowsForms Forums.

Just saw this on the subject also.