Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION]
"Fitbit Connect.exe"=dword:000022b8
Param([Parameter(Mandatory=$true)][string]$Path);
$excel = New-Object -ComObject Excel.Application
$xlWindows=2
$xlDelimited=1 # 1 = delimited, 2 = fixed width
$xlTextQualifierDoubleQuote=1 # 1= doublt quote, -4142 = no delim, 2 = single quote
$consequitiveDelim = $False;
$tabDelim = $False;
$semicolonDelim = $False;
$commaDelim = $True;
$StartRow=1
$Semicolon=$True
$excel.visible=$true
$excel.workbooks.OpenText($Path,$xlWindows,$StartRow,$xlDelimited,$xlTextQualifierDoubleQuote,$consequitiveDelim,$tabDelim,$semicolonDelim, $commaDelim);In IE10 and other new browsers one may create MessageChannel objects that have two MessagePorts each connected (w3c spec calls it entangled) to one another such that postMessage on one port results in the message event firing on the other. You can pass an array of ports as the last parameter to postMessage and they show up in the ports property of the message event arg.
The postMessage here is like the worker postMessage and unlike the window and iframe postMessage in that it applies no origin checking:
Unfortunately the origin isn't an optional parameter at the end to make the two postMessages have the same signature.
On the event handler side, the event arg always has an origin property. But in the no origin case it is always the empty string.
There is also a source property on the message event arg which if set is an object that has a postMessage property allowing you to post back to your caller. It is set for the origin case, however, in the no origin case this property is null. This is somewhat reasonable because in the case of MessagePort and Workers there are only two endpoints so you always know the source of a message implicitly. Unlike the origin case in which any iframe or window can be calling postMessage on any other iframe or window and the caller is unknown. So not unreasonable but it would be nice if the source property was always set for consistency.
When a MessageChannel is created it has two MessagePorts, but until those ports are started they will queue up any messages they receive. Once started they will dispatch all queued messages. Ports don't have to be started to send messages.
A port may be started in two ways, either by explicitly calling the start method on the port, or by setting the onmessage callback property on the port. However, adding an event listener via addEventListener("message", does not start the port. It works this way in IE and Chrome and the spec states this as well.
The justification is that since you can have only one callback via onmessage that once set you must implicitly be ready to receive messages and its fine to start the port. As opposed to the addEventListener in which case the user agent cannot start implicitly because it doesn't know how many event listeners will be added. I found Hixie stating this justification in geoloc meeting notes.
My third completed Windows Store app is Percent Clock which displays portions of a time span like the time of the day or time until your next birthday, as a percentage. This was a small project I had previously started as a webpage and converted and finished as an HTML JavaScript Windows Store app.
The only somewhat interesting aspect of this app is that its the first app for which I tried charging. I picked the minimum amount for price 1.49 USD as it is a simple app and unsurprisingly it has sold very poorly. I'm considering releasing new instances of the app for specific scenarios:
The Windows Runtime API Windows.Foundation.Collections.PropertySet class is a nice string name to object value map that has a changed event that fires when the contents of the map is modified. Be careful with this event because it fires synchronously from the thread on which the PropertySet was modified. If modified from the UI thread, the UI thread will then wait as it synchronously dispatches the changed event to all listeners which could lead to performance issues or especially from the UI thread deadlock. For instance, deadlock if you have two threads both trying to tell each other about changed events for different PropertySets.
My second completed app for the Windows Store was Words with Hints a companion to Words with Friends or other Scrabble like games that gives you *ahem* hints. You provide your tiles and optionally letters placed in a line on the board and Words with Hints gives you word options.
I wrote this the first time by building a regular expression to check against my dictionary of words which made for a slow app on the Surface. In subsequent release of the app I now spawn four web workers (one for each of the Surface's cores) each with its own fourth of my dictionary. Each fourth of the dictionary is a trie which makes it easy for me to discard whole chunks of possible combinations of Scrabble letters as I walk the tree of possibilities.
The dictionaries are large and takes a noticeable amount of time to load on the Surface. The best performing mechanism I found to load them is as JavaScript source files that simply define their portion of the dictionary on the global object and synchronously (only on the worker so not blocking the UI thread). Putting them into .js files means they take advantage of bytecode caching making them load faster. However because the data is mostly strings and not code there is a dramatic size increase when the app is installed. The total size of the four dictionary .js files is about 44Mb. The bytecode cache for the dictionary files is about double that 88Mb meaning the dictionary plus the bytecode cache is 132Mb.
To handle the bother of postMessage communication and web workers this was the first app in which I used my promise MessagePort project which I'll discuss more in the future.
This is the first app in which I used the Microsoft Ad SDK. It was difficult to find the install for the SDK and difficult to use their website, but once setup, the Ad SDK was easy to import into VS and easy to use in my app.
My first app for Windows 8 was Shout Text. You type into Shout Text, and your text is scaled up as large as possible while still fitting on the screen, as you type. It is the closest thing to a Hello World app as you'll find on the Windows Store that doesn't contain that phrase (by default) and I approached it as the simplest app I could make to learn about Windows modern app development and Windows Store app submission.
I rely on WinJS's default layout to use CSS transforms to scale up the user's text as they type. And they are typing into a simple content editable div.
The app was too simple for me to even consider using ads or charging for it which I learned more about in future apps.
The first interesting issue I ran into was that copying from and then pasting into the content editable div resulted in duplicates of the containing div with copied CSS appearing recursively inside of the content editable div. To fix this I had to catch the paste operation and remove the HTML data from the clipboard to ensure only the plain text data is pasted:
function onPaste() {
var text;
if (window.clipboardData) {
text = window.clipboardData.getData("Text").toString();
window.clipboardData.clearData("Html");
window.clipboardData.setData("Text", util.normalizeContentEditableText(text));
}
}
shoutText.addEventListener("beforepaste", function () { return false; }, false);
shoutText.addEventListener("paste", onPaste, false);I additionally found an issue in IE in which applying a CSS transform to a content editable div that has focus doesn't move the screen position of the user input caret - the text is scaled up or down but the caret remains the same size and in the same place on the screen. To fix this I made the following hack to reapply the current cursor position and text selection which resets the screen position of the user input caret.
function resetCaret() {
setTimeout(function () {
var cursorPos = document.selection.createRange().duplicate();
cursorPos.select();
}, 200);
}
shoutText.attachEvent("onresize", function () { resetCaret(); }, true);Redmond finally joins Google, Mozilla, by offering cash rewards for security flaws.
Good news everyone! Of course Microsoft employees are not eligible but that’s probably for the best.
The Windows Store supports refunds and as the developer you are responsible for fulfilling those refunds even after Microsoft pays you. That seems reasonable I suppose but there’s no time limit mentioned…
"g. Reconciliation and Offset. You are responsible for all costs and expenses for returns and chargebacks of your app, including the full refund and chargeback amounts paid or credited to customers. Refunds processed after you receive the App Proceeds will be debited against your account. Microsoft may offset any amounts owed to Microsoft (including the refund and chargeback costs described in this paragraph) against amounts Microsoft owes you. Refunds processed by Microsoft can only be initiated by Microsoft; if you wish to offer a customer a refund, directly, you must do so via your own payment processing tools."
Wrote some scripts that produce .cmdtree files. Nice to find this format definition.
How To Screen Capture on the Microsoft Surface RT - Surface Geeks Surface Geeks
tl;dr: hold windows logo on the surface (not keyboard) and press volume down button on the surface
Some very H. P. Lovecraft style redesigns of some classic Win95 UI.
Breakdown of the bytes of a Windows executable in a big old chart!
But if Surface is aimed at the OEMs—telling them “we can do this just as well as you can, if we have to”—and setting them a challenge—”your tablets have to be at least this good”—then the limited availability isn’t necessarily such a big deal. As long as the OEMs heed the warning and raise their game, so that Redmond can be assured that bad hardware won’t jeopardized Windows 8’s success, Microsoft could safely keep Surface operating as a small-scale operation, playing the Nexus role without upsetting the PC market.
The Verge has the best earliest coverage of the Microsoft Surface press conference and pretty photos.
Microsoft Surface event 2012: everything you need to know
Some rights reserved