From the IE Blog: we’ve also rebuilt the <select> element as a windowless control
.
I noticed this first via Web Standards Project Buzz, where Lloydi rightly hopes they’ve fixed IE‘s myriad other SELECT problems.
As evidenced by my IE Bug Wiki participation, IE SELECT bugs demo, and IE bug solutions, this means a lot to me.
There’s a ton of other great news from the IE team there, including Page Zoom, tabs, integrated search, and Quick Tabs. It sounds awesome — don’t miss it!
I upgraded another client’s SBS 2003 machine to SP1 this past weekend. It went remarkably smoothly, but we forgot to check their smartphones’ access to Exchange til today. No connection, we checked the /OMA virtual directory, and got this error:
“A System error has occurred while processing your request. Please try again. If the problem persists, contact your administrator.”
Much “jiggling” (yknow, rerunning wizards, regenerating the web certificate, etc), and googling got me no answer. I did see this error in the Application Log, though:
An unknown error occurred while processing the current request: Message: The remote server returned an error: (403) Forbidden. Source: Microsoft.Exchange.OMA.ExchangeDataProvider Stack trace: at Microsoft.Exchange.OMA.ExchangeDataProvider.OmaWebRequest.GetRequestStream() at Microsoft.Exchange.OMA.ExchangeDataProvider.ExchangeServices.GetSpecialFolders() at Microsoft.Exchange.OMA.ExchangeDataProvider.ExchangeServices..ctor(UserInfo user) Message: Exception has been thrown by the target of an invocation. Source: mscorlib Stack trace: at System.Reflection.RuntimeConstructorInfo.InternalInvoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean isBinderDefault) at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes) at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes) at Microsoft.Exchange.OMA.UserInterface.Global.Session_Start(Object sender, EventArgs e) Message: Exception of type Microsoft.Exchange.OMA.DataProviderInterface.ProviderException was thrown. EventMessage: UserMessage: A System error has occurred while processing your request. Please try again. If the problem persists, contact your administrator. Source: Microsoft.Exchange.OMA.UserInterface Stack trace: at Microsoft.Exchange.OMA.UserInterface.Global.Session_Start(Object sender, EventArgs e) at System.Web.SessionState.SessionStateModule.RaiseOnStart(EventArgs e) at System.Web.SessionState.SessionStateModule.CompleteAcquireState() at System.Web.SessionState.SessionStateModule.BeginAcquireState(Object source, EventArgs e, AsyncCallback cb, Object extraData) at System.Web.AsyncEventExecutionStep.System.Web.HttpApplication+IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
What a mess. But I recognized that “(403) Forbidden” as a web server error (although not on the actual OMA directory). Combining that with info from similar OMA issues, I checked the /exchange-oma virtual directory’s settings, and aha! it was denying access to all IP addresses except 127.0.0.1 and one we don’t use. It was not making an exception for the primary local address. So I added that and all’s now good.
So when you’re having OMA problems, try the usual stuff (including checking the OMA virtual directory), then also check settings on the exchange-oma virtual directory.
Lesson learned.
Update 2008-11-07:
Ha! I was troubleshooting for a customer, and found my own post (top of the google to ya, 3 years later!) It wasn’t the same issue, but it was similar enough to set me on
the right track.
I’ve been fighting with Outlook development again lately, custom form development in particular. OL development is quirky, but there’s one circumstance where it’s downright bug-ridden:
Custom Outlook forms using Windows’ standard Common Dialog control.
The issues are numerous, but I’ll list them as I’ve found them:
That link is to a thread in which Sue Mosher herself participates regarding her book’s suggestion to use the Common Dialog on Outlook forms. A reader discovered licensing issues with this, and Sue confesses “I think we didn’t get it right, alas”.
Kudos to her for that. But there is a workaround: when I ran into the same issue several months ago, I found (can’t remember where right now, but I’ll update if I do) that, due to the Common Dialog’s (annoyingly dumb!) licensing, there’s a right way to use it and a wrong way. Basically, if you programmatically create the control object, licensing restrictions kick in, and it will only work on machines with MS developer tools installed. However, if you drag/drop the control onto the form, you can programmatically use it without a hitch.
So, drag/drop the control and code to it, instead of using code like CreateObject("MSComDlg.CommonDialog"), and you should be good.
(Some?) Runtime VBScript Errors on Custom Outlook forms are suppressed. Even with On Error Goto 0 explicitly set (which is the default in VBScript anyway), certain object-related errors are simply never raised.
In particular, I was never actually getting the “The control could not be created because it is not properly licensed” error when I ran into it on users’ machines (who didn’t have MS dev tools installed). Instead, that code was simply never running (as if I had On Error Resume Next set). The only way I could track it down was by moving the code into a Windows Script, where native VBScript error handling does work:
…Not a great error message, but enough to google the answer.
If you drag/drop a Common Dialog onto the form, it shows as a placeholder icon. Save and the form template, reopen the template, and that placeholder icon is gone.
I did determine that the Common Dialog is actually still there though. I simply wrote some code which uses the control — when I reopen, that code still finds and uses the invisible control without issue. Pretty confusing to anyone who doesn’t know/remember it’s there, though!
Outlook 2002 SP3 and Outlook 2003 have a security feature which restricts ActiveX controls on one-off forms. Basically, if you open a form template or one-off form which contains an ActiveX control, OL blocks the control and gives this error:
The solution to this problem is to not use one-off forms, and to instead publish them.
Unfortunately, this is not that issue, but it’s a somehow related OL bug. What I found is that:
With items created from published custom form, which possess both custom fields and a Common Dialog control, if you save data in one of the custom fields, then you will get that error dialog on future openings of the item.
So another way of putting it:
…I’ve found no documentation of this issue with this set of circumstances. (Maybe it’s that rare, but I strongly suspect others have had it, which is why I’m airing it here).
It’s also a showstopper for me — I painstakingly worked around the myriad other Common Dialog issues, but I gotta open a file and have custom data on my form. So now I’m looking into other controls. Hopefully Sue was right in suggesting Word’s file dialog. I don’t like the external dependency, but I’ve checked and it appears I can do that (this time). OR, there’s also Windows’ native Shell.Application object’s BrowseForFolder method (which apparently has its own quirks).
For those considering embarking on the Common Dialog route, I’d recommend against it. There are lots of alternatives. I’ll post my results with those later.
Update:
…Not bad at all. Still nice & snappy, with WinXP as the only requirement (certainly palatable for me).
Admittedly, I haven’t seen the beta yet, but I figured I’d get this out there in the hopes that someone who matters sees it…
Great idea for Windows: User Profile Templates and Machine Templates. Essentially, they are just collections of registry settings, editable through a Tweak UI-like interface, and (most importantly) saveable as files.
These templates can be applied to existing profiles or the default user profile. They would be editable and easily transferrable as files (Why? Because even though I’m a power user, I still like the Welcome screen).
Windows would include these Profile Templates out of the box (with example setting changes):
Simple Folder View is disabled.
I don’t care if the default templates are editable, but if not, they should be copyable as the basis for other custom templates. (If so, they’d need a “restore default settings” option).
Same idea here, but for machine-wide (HKLM) settings. Default templates would be something like:
For Users: short of a new “GPOs for Workgroups” feature (which I’d love), power users need a way to manage workgrouped machines. Even plain ol’ Power Users with Standalone Machines need an easy way to setup a machine which doesn’t require two hours of fixing stupid defaults. Profile and Machine templates would greatly mitigate these issues for users.
For the Windows team, these templates would lessen the dev struggle between Features and Beginner simplicity. Got a great but possibly-confusing feature? No problem, just disable it for Beginners, and enable it for Power Users.
Also, miscellaneous Windows Explorer fixes/improvements I want:
I realize some of these are advanced features
That’s the actual title of a scribble note I made a long time ago.
See, while I mostly love Outlook 2003, and it’s greatly improved since v2000, it still has a bunch of annoyances and artificial limitations that really get my goat. To finish dumping the note:
I noticed most of these while trying to maintain multiple accounts in Outlook, and keep their contents separate. I used to use Outlook profiles, but switching is way too slow for that to be convenient.
Googling just now, I found a couple similar ruminations on the same subject: Limitations of Outlook (without Exchange) at inluminent.com, and
Outlook Limitations at outlookwise.com
More as it bugs me.
Apparently MSN Spaces is now much more customizable, thanks to their new “Tweak UI PowerToy”.
Hey wait, though, Doesn’t Microsoft already already have a “Tweak UI Powertoy”?! Ah, so they do! (An indispensible Windows customization program, BTW).
Well, that’s ok, because MSN says to load it by typing “&powertoy=tweakomatic” on the end of the URL. So perhaps we can just call it “Tweakomatic”…
Whoops, Microsoft already has a program called “Tweakomatic” too! It writes scripts to programmatically accomplish what Tweak UI does.
…I can understand if the Spaces team really wants to be like the Scripting Guys (heck, I do!), but the name confusion has got to go!
Ah, if only the CSS Zealots would admit it’s really “Anti-Table” design. Use the right tool for the job, I say.
via the Scobleizer…
Rough week for Firefox team.
That’s a lotta badness for what is hardly a “new” browser anymore.
I have a new client who recently guessed their way through a SBS 2003 setup. THEN they called us to fix it. This has been quite the cleanup. I gotta get me a Haz-mat suit. Imagine and enjoy at my expense, some highlights:
And now (drumroll please)…
Crap.
So I just saw this on Ajaxian Blog: “Ajax is rocket science”. “Ajax isn’t simple”. Enough already!
It makes good points, but what puzzles me is: who is saying this? I never found Ajax difficult (even when I first discovered it 5 years ago).
Are the complainers just web designers, who just build pretty-but-static HTML pages and don’t know coding (-vs- web developers, who build web apps)?
Well, as Scott would say:
And then I got back to work.