Entries for rasx

Blog Comment Spam Caused by Google (Blogspot.com) [Blog Comment Spam Caused by Google (Blogspot.com)]

rasx — Tue, 11 Apr 2006 20:31:16 GMT

With all due respect to the terrible infants at digg.com who may have pinged this “a long time ago,” I notice that my WordPress.org spam comments in moderation are coming from Google, its blogspot.com site. For the last few days, I’ve been stimulated by the possibility of eliminating all comment spam from my moderation queue—but some witty person(s) out there is holding blogspot.com hostage.

The implication is that someone has the ability to set up dummy accounts at blogspot.com and use them as spam robots probably from another zombie-controlling machine. I am surprised that the kids in the hall for dig.com are not up in arms about this one… Maybe Microsoft should unleash this one the wired world to rouse some anger.[6]

in reply to Blog Comment Spam Caused by Google (Blogspot.com)

GoDaddy.com Does Not Support REST Calls for ASP.NET 2.0 [GoDaddy.com Does Not Support REST Calls for ASP.NET 2.0]

rasx — Mon, 14 Nov 2005 22:00:46 GMT

Are you hip to the jive? Well let’s go daddy—go! So dig this:

string uri = "http://songhaysystem.com/xml/amazon_rest_calls.xml";

WebPermission perm = new WebPermission();

perm.AddPermission(NetworkAccess.Connect, uri);

perm.Demand();

I do not like to be right about things like this—so do not hesitate to tell me that I am wrong. It appears that the last line of code above will always throw an error for shared hosting accounts running on .NET Framework 2.0 (ASP.NET 2.0). This means that ASP.NET 2.0 REST calls are impossible for GoDaddy.com shared hosting customers.

Since I have already contacted GoDaddy.com and have an understanding about their attitude regarding this problem, this is an opportunity for competitors out there to let me—and other GoDaddy.com customers—know how you deal with this problem. Is this a Microsoft “locked trust” problem? Is this just a configuration issue under the control of GoDaddy.com?

in reply to GoDaddy.com Does Not Support REST Calls for ASP.NET 2.0

Reverse Engineering the MSDNTV Episodes Page [Reverse Engineering the MSDNTV Episodes Page]

rasx — Fri, 18 Feb 2005 23:10:07 GMT

This probably has been obvious for many web architects but I am now guessing that the MSDNTV archive links to one page (espisode.aspx) that then loads thousands (or millions) of little XML files (manifests?) with the same schema.

This means that InfoPath users can create and edit these XML manifest files and save them to a location where the web site code finds them. This is a quick and dirty static publishing model that works perfectly for small business people who already have Microsoft office with InfoPath—dropping SharePoint into the mix can’t hurt (too much) as well.

in reply to Reverse Engineering the MSDNTV Episodes Page

Flippant Remarks about AbiWord 2.014 [Flippant Remarks about AbiWord 2.014]

rasx — Thu, 13 Jan 2005 01:01:53 GMT

I am a Microsoft guy for historical and practical reasons---not for ideological reasons. When some Oracle guy has a smart remark, I say, Hey, smarty slacks, back in the early 1990s when I was learning SQL I could not walk into an Office Depot and pick up a $99 Oracle database (with that special, software-laundering, anti-trusting "competitive upgrade" price). But I could get my hands on Microsoft products and this got me hooked---the MS Borg assimilated another victim.

Now that my Office Depot days are over, here comes MSDN Universal Subscriptions via my W2 labors---so now I'm on the harder stuff and from my W2 point of view I am getting Microsoft software "for free." So why would I care to write about AbiWord, this Open Source fledgling?

Well, Microsoft employees can console themselves by considering my flippant remarks a minority opinion (in every sense of the term) but I don't think I am suffering from a terminal case of brown-eyed myopia when I say that MS Office is a bloated nebula of COM objects---composed of balls of strange orange gas and truly stellar objects. The gassy part of MS Office is really starting to stink when I think of my data as cross-platform XML data sets---and I am writing this sentence being fully aware of InfoPath and the XML features in Word 2003. So when I hear that AbiWord can read and write XHTML, I sit up and take notice. Unfortunately, these are the first few AbiWord bullets flying past my head:

* AbiWord 2.014 provides no way to edit http: or mailto: hyperlinks that I can see, coming from a Microsoft Word perspective (which means I right-click on the hyperlink and I see a command like Edit Hyperlink). This non-feature alone drives me away from AbiWord 2.014.

* The toolbars in AbiWord 2.014 are out of the early 1990s. Don't take me back.

* Features that resemble replacing-text-as-we-type (Auto-Correct or Intelli-Sense) does not appear to be in AbiWord 2.014. And I say this while seeing the Insert > AutoText command in AbiWord 2.014.

* The kerning and hinting information of the default font in the Windows version of AbiWord 2.014 does not appear to be recognized. Inconveniences like these may be beyond AbiSource control. I am aware of how hostile Microsoft can be to its competitors big and small.

* I see nothing in AbiWord 2.014 that handles XML Schema information. I do not think that AbiWord 2.014 is designed from the ground up to be part of an XML workflow. Microsoft is trying to begin to start thinking about tinkering with XML-based products but the design goals at Microsoft are preoccupied with domination instead of integration (and of course another patch Tuesday is coming up).

The main point of this rant is that I am completely unaware of a tool that is as convenient as a Word processor but it also is a built for rich data interchange. With MS InfoPath the price of entry is having a definite schema in mind. With MS Word 2003 you don't need to have a definite schema to get started (you can add that later), but the formatting of your document effectively---by default---belongs to Microsoft. Out of the box, Microsoft Word 2003 will allow you to interchange your raw text data with a custom schema but it will not let you interchange your formatting information with a custom schema---and I say this with the letters WORDML dancing in my head. I suppose you can "schema-tize" your formatting but the temptation to write your own code is not far away (and I am well beyond tempted). This limitation is unacceptable and as long as Microsoft pays little or no attention to this "minority problem" I will keep my brown eyes on tools like AbiWord.

in reply to Flippant Remarks about AbiWord 2.014

The Importance of Multi-Threading Handlers [The Importance of Multi-Threading Handlers]

rasx — Tue, 26 Oct 2004 21:11:31 GMT

Tuesday, October 26, 2004: Understanding Chris Sells Teachings about Multi-Threading in Windows Forms: The Importance of Multi-Threading Handlers

Chapter 14 of Chris Sells, his book Windows Forms Programming in Visual Basic .NET (with Justin Gehtland on drums) explains all we need to know about implementing multi-threading designs in all but the most complex Windows Forms. Unfortunately, I had to read this chapter about five times and I had to send several stern emails to Chris Sells (which he generously answered) before I understood these basic bits:

· Creating a worker thread can be an indirect procedure (by calling BeginInvoke) or it can be a direct procedure by getting a new Threading.Thread object. Sells discuses the disadvantages of using the latter method but I find I am able to name a new Threading.Thread object and sets is priority—I will tentatively call these “advantages.”

· Think about implementing multi-threading handlers in the same manner you think about implementing error handling: every method that interacts with the UI thread (and is likely to be called from a worker thread) must be designed with a pattern that interrogates the Boolean InvokeRequired for true. The following is the Chris Sells multi-threading handler design pattern (written with my sense of style):

Delegate Sub MySubDelegate(ByRef WinForm As MyNameSpace.MainForm)

Sub MySub(ByRef WinForm As MyNameSpace.MainForm)



    If WinForm.InvokeRequired Then

        Dim del As MySubDelegate _

            = New MySubDelegate(AddressOf MySub)

        Call WinForm.BeginInvoke(del, New Object() {WinForm})

    Else

        With WinForm

            'TODO: Do stuff to objects on the UI Thread.

        End With

    End If



End Sub

'How will Windows Forms 2.0 eliminate the need for this pattern?

· When InvokeRequired is always true, the flawed design is probably calling Invoke() or BeginInvoke() from an object created on the worker thread. The design pattern above avoids making this mistake by clearly showing that it is WinForm making the call (there is, believe me, the temptation to use del.BeginInvoke, which is incorrect—it puts wrinkles in Sells’ Burning Man kilt!).

· Calling back to the UI thread from the worker thread means calling from an object that ultimately derives from System.Windows.Forms.Control that was instantiated by the UI thread.

· The ISynchronizeInvoke interface contains the aforementioned worker-thread-to-UI-thread method invocations and the Boolean indicator that such an invocation is required. As of this writing, only one class implements this interface System.Windows.Forms.Control. Explaining why the ISynchronizeInvoke interface exists in the first damn place would have gone a long way toward why multi-threading handlers are important.

· There is the temptation to make all Windows Forms event handlers multi-threading handlers as well. I find that this design goal creates too much code what with the writing of delegates for every single event handler. Another way is to not set form control properties directly in event handlers but to create a Client Layer of static methods that set Windows Forms controls, each with their delegates and multi-threading handlers.

· When all of the above bits are found to be valid and not addressed by Windows Forms 2.0 kudos to the brilliant author who thunk it all up! Until then, these ideas are all my fault. Sorry, Chris.

in reply to The Importance of Multi-Threading Handlers

WSE 2.0 Services can replace some "old" Windows Services? [WSE 2.0 Services can replace some "old" Windows Services?]

rasx — Sun, 17 Oct 2004 08:38:48 GMT

VB6 guys would always brag about creating their first Windows Service. Now, the same VB.NET blokes would brag about creating their first Service—no, not Web Service or Windows Service, just Service. WSE provides this capability. This is attractive to me for the following reasons:

· Code access security “complications” should not be an issue with these services. The assumption here is that the code is started by a privileged user—and the code is called by users of unknown security permissions (outside of the context of WSE security features). We may not have to be so devoted to the principle of coding for least privilege.

· The “old” Windows Service components are bound to its hosting OS per machine while modern Service components “live” in an abstract layer punctuated with SOAP TCP addresses.

The “DTS assembly” I just built a few days ago, loaded by reflection, looks like it can loaded by WSE instead. I am certain that loading an assembly with reflection has more security complications than simply calling a Service running under higher privileges.

in reply to WSE 2.0 Services can replace some "old" Windows Services?

Inheriting the Designer of ASP.NET Controls [Inheriting the Designer of ASP.NET Controls]

rasx — Tue, 14 Sep 2004 22:37:40 GMT

So, here I am actually trying to drink the Kool-Aid™ and I can’t find the cup! I am stepping away from writing it all in code and trying to inherit a control from, say an HTML Label control such that I am able to manipulate this control in the Visual Studio designer without building my own designer from the ground up.

I erroneously thought that I can just drop a Designer Attribute referring to the HTML Control Designer (or even the Intrinsic HTML Control Designer) and somehow Visual Studio would show me the appropriate Label-derived designer.

Are we forced to build our own designer for all controls we write? Is there any concept of “designer inheritance” addressed in ASP.NET 2.0? Please feel free to tell me that this question has been answered in your favorite Blog-style newsgroup so that I can find my answers there. Or it would be cool to answer a technical question here for a change.

in reply to Inheriting the Designer of ASP.NET Controls

Meta-Applications: SPS, WSS, Project Server [Meta-Applications: SPS, WSS, Project Server]

rasx — Thu, 09 Sep 2004 23:52:08 GMT

9/9/2004 4:21:09 PM: Meta-Applications

Microsoft is so big that it develops software applications for its other software applications. It’s a self-join of monumental proportions. It’s quite a jump from some kid hacking together a small VB6 app’ or a tiny toy Access form.

Windows SharePoint Services, SharePoint Portal Server, Office Project Server and SQL Server

All of these mugs are now installed on one Windows 2003 server. After installing SP1 for WSS and SPS, I was able to run WSSWIZ.EXE that dumped some templates on SPS (including some Project Server web parts). This executable was a step defined in MS KB Article 840701 (“How to install SharePoint Portal Server 2003, Windows SharePoint Services, and Project Server 2003 on the same server”).

Now I thought I was being conservative when I installed SPS on top of MSDE but Office Project seems to require SQL Server (preferably with analysis services). Also, Project Server still uses ASP files so SPS has to be configured to allow this file type. And Window Server 2003 has to be configured as well. Both configurations reduce the level of security.

Those Phong-shaded cartoon drawings of happy perfect applications holding hands with other happy applications are quite annoying when the gritty complicated reality is faced. To make life easier I should have set up at least two virtual machines because Microsoft does not recommend running Office Project and SharePoint Portal servers on the same machine. But I can’t imagine having less problems running multiple, virtual, Windows 2003 servers on one machine.

Interoperability and backwards compatibility is starting to become a seriously heavy burden.

in reply to Meta-Applications: SPS, WSS, Project Server

Completely Removing the Xamlon Beta [Completely Removing the Xamlon Beta]

rasx — Tue, 07 Sep 2004 00:04:59 GMT

Now that the real XAML is coming to pre-Longhorn platforms and now that I have seen the forms designer for the Xamlon beta, I have uninstalled Xamlon.

Unfortunately, the Xamlon icon shows up among the products of the Visual Studio "family" on the VS.Net splash screen. Any ideas about removing Xamlon from the splash?

in reply to Completely Removing the Xamlon Beta

Dvorak says, "Kill Microsoft Word" [Dvorak says, "Kill Microsoft Word"]

rasx — Mon, 30 Aug 2004 22:21:09 GMT

The story is here.

And here I ask the following:

Is it just possible that MS Word is tangled up like PageMaker?

For those who care, Adobe was relatively honest about the C++ prose mess that PageMaker makes. So Adobe explicity rebuilt PageMaker from the ground up as InDesign using "cleaner" OOP principles.

How many Channel9 people use MS Word?

in reply to Dvorak says, "Kill Microsoft Word"

Data Adapter Configuration Wizard Does Not Cast Evil Spell [Data Adapter Configuration Wizard Does Not Cast Evil Spell]

rasx — Wed, 25 Aug 2004 21:53:48 GMT

I was wrong about this problem. No problem. Declare this thread null.

in reply to Data Adapter Configuration Wizard Does Not Cast Evil Spell

Threading Windows Forms [Threading Windows Forms]

rasx — Sun, 22 Aug 2004 19:08:41 GMT

Chapter 14 of Chris Sells’ Windows Forms Programming book introduces the importance of thread safety. My first impression was that my application is in danger of crashing based on statements like, “…we recommend that in every method that might be called from a worker thread, use a call that asserts that InvokeRequired is not required.” So not making this assertion means danger.

So what I did in response to this danger was to follow their design patterns on a structure that was quite different from their scenarios. My thread calls a method that runs a DTS package, which in turn calls events that use the UI thread extensively. I went so far as to wrap up each DTS event with delegates and callbacks (because I was using BeginInvoke to prevent blocks—and Chris Sells insists that you must use callbacks based on his reading of a KB Article). What I ended up with was performance problems. The DTS OnProgress event would fire too late because it was marshaled in a queue somewhere. I stopped using a Thread object and “lost” the ability to control priority.

Presently, having read Justin Rogers’ review of threads and a few VS.NET help files, the “crash” will occur when two or more threads (usually the UI thread and some worker threads) call the same control. So I stripped all the “safe” code out and will assume that this will never happen because this project is not being built by a large team of developers that may build a widget that will compete with my widget for a text box. Will the new BackgroundWorker component in Visual Studio 2005 be able to handle all of the problems mentioned and implied here?

in reply to Threading Windows Forms

It’s Not about Cultural Sensitivity; It’s about Not Being a Savage [It’s Not about Cultural Sensitivity; It’s about Not Being a Savage]

rasx — Thu, 19 Aug 2004 20:55:19 GMT

This article from CNET, “How eight pixels cost Microsoft millions,” shows yet again that this is not a matter of being “sensitive” to other cultures, like some prancing wimp. It is about being educated, strong and graceful. Can you describe any Microsoft products with words like “strong” and “graceful”? (I’m personally close to that when I work with SQL Server, as this product never disappointed me.)

Just because someone has an MBA, does not mean this person is educated. Most of the people we consider educated are actually specialists bordering on idiot-savant mentality, handing out biased, narrow, standardized tests of intelligence. The mindset behind those famous French words, “let them eat cake” is not gone.

It is not matter of “whiners” like me waiting for the people I am “begging” to switch on their humanity and see the full spectrum of the light. This is just a reminder of the blindness surrounding me. See what I mean?

in reply to It’s Not about Cultural Sensitivity; It’s about Not Being a Savage

SQL Server and InfoPath [SQL Server and InfoPath]

rasx — Tue, 17 Aug 2004 23:46:13 GMT

The following were posted directly to the InfoPath Team. I am posting these here assuming that you folks can answer these questions as well:

Tuesday, August 17, 2004: Open Post to the InfoPath Team
The assumption here is that the ADO 2.8 security settings are NOT configurable by developers. So when an InfoPath form connected to a database via an ODC file throws up an ADO Security Warning we have no way to stop this, apart from taking the time to build a web service. Is this correct?

8/17/2004 4:31:01 PM: Open Post to the InfoPath Team
Is there a way to persuade InfoPath to infer a recursive schema from a self-join in a SQL Server database? Once this is achieved, the new SP1 recursive controls should work as advertised for database connections.

in reply to SQL Server and InfoPath

MS Office Information Bridge Framework [MS Office Information Bridge Framework]

rasx — Thu, 12 Aug 2004 23:11:17 GMT

Is anyone out there eagerly awaiting the Microsoft Office Information Bridge Framework? I am wondering is this an answer to my gripe about Don Box stopping work on transforming WordML into XHTML. Save me from reading a 153-page whitepaper!

Will this framework allow me to right-click on a paragraph in a Word 2003 document and route the contents of its Range object to a web service? Will I be able to send formatted XML before routing?

I assume that MOIBF is more concerned about sending entire Office XML documents to web services rather than drilling down to the Excel Cell or Word Paragraph level.

in reply to MS Office Information Bridge Framework

XHTML, the RTF of the Future (InfoPath SP1)! [XHTML, the RTF of the Future (InfoPath SP1)!]

rasx — Fri, 09 Jul 2004 20:53:25 GMT

XHTML, the RTF of the Future!

The InfoPath team would agree with me when they finally get that darn SP1 RTMmed! XHTML is the RTF of the future. In InfoPath, the “Rich Text” control is not stuffing old-school RTF into CDATA blocks. It is actually producing XHTML. Unfortunately the XHTML formatting rules are controlled by Microsoft so this may mean more hours of misery trying to XSLT my way out of this future problem.

It would be a joyous day when InfoPath provides an option for the Rich Text control to Render as Open Doc instead of dropping div tags all over the place! However, the sense here is that InfoPath Rich Text controls are designed for short bursts of prose or one or two paragraphs (oh, I mean div blocks)—say, up to 8000 characters. This design goal goes hand in hand for lack of support for text/ntext columns in SQL server.

I’m waiting for InfoPath 2010’s support for serializing binary structures!

in reply to XHTML, the RTF of the Future (InfoPath SP1)!

Is the MSDNTV RSS Feed Not Automated? [Is the MSDNTV RSS Feed Not Automated?]

rasx — Wed, 07 Jul 2004 22:08:20 GMT

Is the MSDNTV RSS Feed Not Automated?

The RSS feed for MSDNTV did not automatically update itself when Craig Skibo’s Building Tools Using the Visual Studio Automation Model appeared yesterday. Are they using a bunch of unmanaged flat files to run the site? It is instructive to learn that the management of data is challenging even among the best of us. Someone@msdn.microsoft.com is dealing with this problem and is courageously eating their own dog food.

in reply to Is the MSDNTV RSS Feed Not Automated?

Flippant Remarks about David Berlind's "Microsoft's patchwork mess"; ZDNet; Download.Ject; [Flippant Remarks about David Berlind's "Microsoft's patchwork mess"; ZDNet; Download.Ject;]

rasx — Sun, 04 Jul 2004 01:13:29 GMT

ZDNet Executive Editor, David Berlind, "Microsoft's patchwork mess" (July 3, 2004) writes:

"The notice, which was posted on Microsoft's site by 9 a.m. on July 2, 2004, says the Windows Update service will be distributing the fix later in the day. People who want to move more quickly are directed to download the code from Microsoft's Download Center."

"But clicking the link will lead to a page that offers not a clue about where to find the fix that Microsoft says is there. The site lists popular downloads and even featured downloads. But nowhere is something that says, 'If you've come here for the download that protects you against Download.Ject, click here!'"

This story underscores a huge chunk of my life's work (so far). A non-technical manager should have been able to post a change to the relevant web pages in the relevant web sites but clearly this did not happen. My guess is that the site in question is not database driven---or the database behind this web page(s) is not web-service driven--or the web service---well, you get the idea.

I'm seeing some Microsoft program manager updating Microsoft websites with as much ease as sending an email---with as much ease as opening a "master document" in a Word Processor and routing an updated paragraph in that document to the appropriate web site. Having seen MSDN web programmers lecture on MSDNTV about XSD schema stuff driving MSDN webs, clearly the tools are there. It is just a matter of making them available to the right people at the right time. And SharePoint Portal Server is not one of those tools.

Why did Don Box stop working on his WordML XSLT transform?

in reply to Flippant Remarks about David Berlind's "Microsoft's patchwork mess"; ZDNet; Download.Ject;