Time to panic? No. Time to give up? Yes. Shutting down. I just had a long chat with my employees of eight years and past along the new. We are closing shop. While we've had our moments, the last several years have been a steady downward spiral. Between the massive tax burden we're under and trying to compete with low-cost (low-quality) sweat shops over seas (just west of China btw...) there used to be only one remaining incentive for success - to send my kids to college in comfort. Now - with Obamacare looming and a line that goes 'round the block of 'citizens' with their hands out pleading with the Gov't, "Please give me even more because you all owe me" and a seemingly endless list of "Programs" designed to sponsor the super-lazy - I see no reason to continue trying to succeed. Thank you Codeproject for giving my crew countless sources of inspiration. I wish you all the very best of luck and success wherever you are able to find it.

Keith Barrow wrote:

Not done much real UI coding then have you? Most people muddle by with bits of UI stuff in their OM or [more commonly] bits of OM in their UI. Stuff is spread across several places repeated etc. Decoupling is the single best thing you can do: the code becomes terser and clearer, do it any other way and you end up with an unmaintainable tangle of spaghetti on any reasonably sized system.

It's all I do - design applications look and feel...there is no 'muddling.' I do agree with you 100% about one of your comments: CAB would be PERFECT for massive cube-shops like Insurance companies or Financial institutions.

Keith Barrow wrote:

I challenge to to plug in a new control without a rebuild or some hand-rolled complicated CAB-like structure.

They're called "USER CONTROLS" and there's something like 35,000 right here on CodeProject. Some are actually pretty cool and omg...you can just plug em in and they work!

Keith Barrow wrote:

...More than allowing controls to be-reused across applications, it allows you to decide which controls are available to a instance running, without a re-build

SO WHAT??? Why would that even be useful? I still see no advantage in writing something so generic that it can be used within multiple applications as-is when those instances are uber rare and again...a user control would pretty much cover that.

Keith Barrow wrote:...instance running, without a re-build. Handy where you want a pluggable environment I'd say, and it helps certain deployment scenarios too.

CERTAIN DEPLOYMENT SCENARIOS? CAB Deployment - You have this .EXE (often referred to as the 'Shell') and it runs independent of the module that choke its almost certain MDI interface...there's an XML file that directs the Shell what OTHER .exe's will get loaded and run (either at launch or via some trigger.) Your department has been working hard for the last 18 months on its CAB module (form/user control) that displays a Contact's First, Last and Middle names... And because you wrote it as a CAB module you can distribute JUST YOUR MODULE.EXE, right!??!?? Wrong. You have to tell Shell.EXE to STOP so you can load the new module...then you have to tell Shell.EXE to start back up again. The ONLY thing you 'gain' is that instead of having to re-release a 700-800k exe you only

_Maxxx_ wrote:

think the idea is that, should this list change in the future (cuz you want to include something new, or change something already on it) that should be easy to do as the list is designed from the ground up to be dynamic.

Can you add to your .XML file and suddenly *poof* it shows up in your application? No. You have to 1) Shut down the original EXE. 2) Deliver whatever it is you wrote to that machine. 3) Restart the EXE. If your lil magic square of bland-UI whatever has zero connection to the rest of the application then what have you gained vs writing a user control that looks better, operates better and was faster to build? Again - I say, 'Nothing' and your previous comment to not prove otherwise.

_Maxxx_ wrote:

You can create a C# application with the .Net runtime and vi - but would you want to? And my understanding of CAB is that the 'overheads' is what makes it more than a user control. I fyou only want a user control just create a user control - if you want the added functionality then use it.

Once again, you have put the cart before the horse - i am asking WHY SHOULD I USE IT? WHAT DO I GAIN?? Just saying, "Well if you use it then you'll have it there to use" is hardly a valid reason to substantially increase development time because of the code-bloat associated with CAB.

_Maxxx_ wrote:

...but there's many a developer arguing about using this or that pattern and practice because they don't understand the benefits and fear the unknown

OMG seriously?? Ayende said it best when he said, "The P&P team doesn't work with their tools on real applications. Basically, these tools are created in vacum, not by having to solve real world problems." and also, "When looking at the stuff that the P&P produce, I see things that are extremely complex to their purpose, hard to use and maintain, and don't really add any value to me from where I stand today. I am not speaking blindly here, it took me 40 minutes to repreduce the policy injection block. Even if some of the stuff that they are producing has good stuff in it, it is usually in a form too abstract to be readily used. The CAB is a good example, I like some of the ideas there, but it comes with so much weight around it that it is not worth bothering. I can build on the same ideas in half a day and end up with a far more light wieght approach, easily

I've read comments and articles 'CAB' developers make about how amazing it is that CAB allows you to create de-coupled applications and how 'disconnected' the UI is from the Business Layer, etc. etc...but to date, I've yet to read a single comment or article explaining why any of that is worthwhile? What am I gaining? Ok great...someone sitting in a cube somewhere with little or no knowledge about what this *specific* application does can write the code to encapsulate all 'modules' under one roof! Woopie? What does that gain you and me? I argue it gains us absolutely nothing. No matter how 'de-coupled' CAB developers claim they are, ultimately there's a file somewhere that contains a list of everything that's included...be that in a Project/Solution file for development or ProfileCatalog.xml file for distribution...the fact is CAB takes physical file requirements and moves them from one location to another solving nothing in the meantime and adding a large amount of barbaric source code just to complete even the simplest of tasks. Ok...how about this: CAB allows us to create 'plugins' that can be shared from one application to another!! Finger-Twirl: You can create 'plugins' without CAB - they're called User-Controls and in fact, that's exactly what a 'module' in CAB ultimately is...a user control with a massive amount of overhead tacked on. We need tools that make our lives simpler not so overly complex that suddenly it takes six engineers where previously it took two. Perhaps my opinion is completely wrong based entirely on my overall lack of knowledge and understanding of CAB but in the last several weeks that I've been investigating CAB I still have not found one single, decent answer to my most basic of questions: What does this gain me? GAIN implies that I get 'something' from CAB that I cannot get without it...and just for the record, saying 'decoupled software' as your answer...is NOT an answer. We lose far more than we gain by decoupling so from my chair decoupling is a negative, not a positive. If you're on the CAB team maybe you can post an answer to the above question.

Like so many thousands of other "lost" customers, Netflix got their last eighteen bucks from me...oh sure, their DVD service is 'decent' but not much better than Red-Box unless you're into some older TV series or movies - but IF YOU WANT TO STREAM anything worth a crap, DO NOT look to Netflix for *insert anything of quality here* WTG Netflix.... See ya!