The Microsoft audio recording example shows how to record audio, but it just gets a PCM encoded stream of samples – if you want to send this audio stream off somewhere else, to be played later, it needs a proper header.
Below I show you how to use a couple of methods I’ve written (WriteWavHeader and UpdateWavHeader), and I include their implementation.
Assuming you start with the Microsoft sample, when you initiate the audio recording you initialize a memory stream into which the samples will be written:
Note the call to WriteWavHeader to write the wav header to the start of the audio stream.
When the recording finishes, you update the header (because we need to fill in fields based on the data length):
Here are the implementations of the WriteWavHeader and UpdateWavHeader methods. The comments come from this web page describing the wav header file format.
For my textboxes I’ve been using a modified version Johan Danforth’s Watermark behaviour (binding the watermark text to a ViewModel property instead of hardcoding the text), but when I needed to do something similar for a PasswordBox I thought I was stuck.
I’ve come up with an incredibly basic, simple solution that seems to work well. Instead of just having a PasswordBox, I also have a TextBox behind it which I make invisible when the PasswordBox has content, or has focus. Because the watermark TextBox is behind the PasswordBox, it never gets focus: it is purely visual.
In the code-behind I hide/show the watermark TextBox and the PasswordBox as appropriate. Note that I show and hide them by changing their opacity, not by setting their visibility.
Because the PasswordBox is in front of the the watermark Textbox, when the user clicks in that area he always clicks on the PasswordBox, even if it is invisible.
When populating the PasswordBox, you can call CheckPasswordWatermark() to show/hide the watermark as appropriate.
Putting the user back to the correct pivot item when they return to a tombestoned application whose last visited page contained a Pivot is pretty easy, but ensuring that they are put back to the right scroll position if they’ve scrolled down a list isn’t quite as easy.
In the code below I have a method which returns the first ScrollViewer under an item. This works well for me, but if your PivotItem’s contents contain ScrollViewers then you’ll need something more sophistacated.
In the OnNavigatedFrom I follow the standard pattern Microsoft recommends, and store away the scroll offset in the page state.
In the OnNavigatedTo I recuperate the scroll position, but cannot yet scroll because the PivotItem’s contents have not been loaded. Instead I store the scroll position, and then when the pivot has been loaded I then scroll. In my XAML I hook up each PivotItem’s Loaded event to invoke PivotItemLoaded