Showing posts with label Bugs. Show all posts
Showing posts with label Bugs. Show all posts

Saturday, 16 November 2013

Slider and IsDirectionReversed–Why doesn’t my app work on WP8 (part 6 of N)

Just when you thought all the bugs must have been ironed out by now, you stumble across a new one.

I’ve recently been updating all of my apps to Visual Studio 2013 so support will be simpler in future, and as a result started porting to WP8 from our old WP7 codebase.

Of course, everything is supposed to just work.  Today we’ll focus on the IsDirectionReversedProperty, which as will see should really be called IsDirectionReversedProperly!

Try sticking this in your WP app:

<Slider Orientation="Horizontal" Maximum="10" IsDirectionReversed="True" />

Can you see where this is going?

Now add Minimum="5" and be amazed that this slipped through testing.

It’s broken on the 720p emulator.  It’s broken on my Lumia 920 with GDR3.  It’s not broken in a WP7 app though.

So, I wonder how Microsoft can fix this out in the wild, (though it only seems to work in any kind of reasonable way if Minimum is set to 0).  Someone may be depending on this behavior.

Sunday, 10 November 2013

RateMyApp challenge on DVLUP code defects and gotchas

If you’re trying to run the RateMyApp challenge over at DVLUP (if you haven’t signed up, you should.  Click the link), you may be interested in a few problems I’ve stumbled across.

First, your app bar will still be active, even if the rating window is open. 

To fix that, you’ll need to wire up to the feedback controls VisibilityChanged event, and then in the handler, set

ApplicationBar.IsVisible = FeedbackOverlay.GetIsNotVisible(feedbackctrl);

Secondly, you’ll find that if you have any touch events, they may be handled as well.  This includes ListBox manipulation and scrolling, so you’ll need to turn that off in the handler too.

And finally, the bug.

If your app has multiple pages you’ll find that on the 5th and 10th run, your user will continue to be pestered every time you navigate back to the main page of your app.

To fix this, I suggest you do the following:

In FeedbackOverlay.xaml.cs add the following to the SetVisibility(bool visible) function inside the bottom of the else statement:

FeedbackHelper.Default.State = FeedbackState.Inactive;

If you don’t, the state will remain the same, even though the FeedbackOverlay was dismissed, so it will continue to be shown.

In addition, you must also change the yesButton_Click handler to SetVisibility(false) at the end of the function, rather than the beginning.

Friday, 10 May 2013

Why doesn’t my app work on wp8 (part 1 of n)

We recently switched over to a Lumia 920 for testing our apps, and have found that some of our apps just don’t work correctly.

For instance, our popular Skied Demon ski logging app exhibits problems on Windows 8 on a Lumia 920.

It turns out that the problem is caused by setting up BitmapCache as the CacheMode on some of the controls to improve performance.  The ironic thing is that this fails on Windows Phone 8 and not on Windows Phone 7.

This may also be caused by the increased screen resolution on this particular phone though I haven’t yet been able to verify that.  I suspect that what’s happening is that a bitmap is being constructed for the size of the zoomed area.  As that size grows, eventually the entire thing falls apart.

However, I would have expected WP8 to behave at least as well as WP7.

So, that’s one (of presumably many to follow pitfalls, as we know at least one more of our apps is currently not working, probably caused by a store issue)

Sunday, 10 March 2013

Windows 8 Winhlp32.exe

It seems Microsoft just can’t get this one right.

Installing some old legacy apps that use Winhlp32 for their help leads you on an out of the box install of Windows 8 to this page:Windows Help program (WinHlp32.exe) for Windows 8, which is KB917607

Unfortunately, installing this update doesn’t actually help on a 64 bit system.

When you do try to launch the installed winhelp, you get a partial title bar describing the problem.

winhlp32

Digging out Spy++ reveals that the actual title continues:

“located in the System directory.”

Moving the file there unfortunately, doesn’t actually help.

So, for the moment, I’m uninstalling by running the downloaded msu file from the update from an elevated command prompt like this:

windows8-RT-kb917607-x64.msu /uninstall

Attempting to install the Windows8-RT-KB917607-x86.msu on either a 32 bit or a 64 bit system claims that “this update isn’t applicable to your computer”

Thursday, 1 November 2012

HP Machines and Windows 8

I’ve had a bad 24 hours.  I’ve been trying to get started developing for Windows Phone 8, and as a result of the new outlandish hardware requirements to do so have had to purchase a new PC.

So, I wandered down to Curry’s and picked up an  HPPavilion g6-2241sa 15.6 Laptop – Blue for £350.  I then had to get the windows pro pack to enable Hyper-V, (which I still haven’t, at the time of writing this, managed)

Alas, I’ve stumbled into the problem that Windows Update on HP machines doesn't actually work very well (if at all).  The big 190 MB update that needs to be done locks up after reboot at 13%

After nearly 12 hours talking to support, I came across this:

http://support.microsoft.com/kb/2777330

What I did was:

go to the windows update site, and download the updates manually: KB2764870, KB2761094, and 2756872 as well as delmigprov.exe

http://www.microsoft.com/en-us/download/details.aspx?id=34908

I then ran delmigprov

did the clean boot thing

copied the files to the desktop

and then went to device manager, and uninstalled all devices that might cause a problem (2x network, card reader, 2xaudio, and web cam).

I also manually stopped the audio services in case it was the IDT audio.After running the first 2 kb updates, I needed to reboot.

Alas, that meant I had to remove all of the devices again, and stop the services after they were installed.

Now my machine has finally booted back into windows!

I am now going to create another system restore point

Since then, I’ve added another 5 windows updates, but this time without disabling the devices.

And now another restore point, and finally install of pro-pack.

All of this seems to have worked, and I’m finally up and running after only 19 hours of work.

If this has saved you time, please consider purchasing some of our software at http://www.wieser-software.com/

Friday, 24 August 2012

Problems subclassing UserControl on WinRT

While trying to figure out how to add a generic mechanism for accelerators on buttons on my Win8 port of Bridge Stenographer I was faced with blank stares when asking about Keyboard Shortcuts

AutomationProperties.AccessKey="Number2" looked like the perfect property to add on my 2 button for instance, but I was disappointed to find out that nothing supported it.

In the end, I needed to have a base class that did some of the handling for my keyboard mapping to the access keys, as I don’t want to write that code over and over again (actually, I don’t want to debug and keep parallel copies up to date, but I digress).

So, what better way than a base class I thought.

So, here’s what I did.  I had my keyboard like control based on a UserControl.  Why not just change the base class to SpecializedUserControl like this:

public class SpecializedUserControl : UserControl
{

public SpecializedUserControl()
{
}

public void ExtraFunctionality()
{
}
}



Then, I can create a new user control, and base it on this new base class like this:


public sealed partial class MySpecializedUserControlInstance : SpecializedUserControl
{
public MySpecializedUserControlInstance()
{
this.InitializeComponent();
}
}


and declare it in XAML like this:

<local:SpecializedUserControl
x:Class="hoverbug.MySpecializedUserControlInstance"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="using:repro"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="d"
d:DesignHeight="300"
d:DesignWidth="400">

<Grid>
<Button>Sorry Charlie!</Button>
</Grid>
</local:SpecializedUserControl>


Interestingly, while writing this, I was disappointed to find that everything worked fine, and I wasn’t getting the error I got in my actual code.


Here’s how I instantiated the control on my page:


<local:MySpecializedUserControlInstance DataContext={Binding }" />


Not to be beaten (as it really didn’t appear to work in my code), I started porting across bits of my implementation, a feature of which was that I needed a property to attach to controls in my implementation that could hold a function to call when the AccessKey was pressed, so I did it like this in SpecializedUserControl:


public RoutedEventHandler KeyboardAction
{
get { return (RoutedEventHandler)GetValue(KeyboardActionProperty); }
set { SetValue(KeyboardActionProperty, value); }
}

// Using a DependencyProperty as the backing store for KeyboardAction. This enables animation, styling, binding, etc...
public static readonly DependencyProperty KeyboardActionProperty =
DependencyProperty.RegisterAttached("KeyboardAction", typeof(RoutedEventHandler), typeof(SpecializedUserControl),
new PropertyMetadata(null));


Now when I run the same program, I get this error:


oops


Anyone have any idea why adding a declaration of an attached property breaks it in this way?

PointerOver visual state on WinRT, it’s over even if it’s not.

I’ve been trying to get my Bridge Stenographer App ported to Windows 8 and in the process have come across a few problems.  The latest being that I click on a button on the welcome page to get somewhere else in the app, and when I navigate back, my button is still in the pointer over state, despite the pointer being elsewhere.

I’ve tracked this down to using  NavigationCacheMode="Required" on the page, in order to keep my page alive.

As a result, when I navigate back to the page, the controls don’t get whatever the equivalent of MouseLeave is, and therefore don’t transition out of the PointerOver state, and this doesn’t just apply to Buttons.  Combo boxes have this behavior as well.

You’ve been warned.

Sunday, 22 July 2012

Win8 WebView not ready for Prime Time

Yesterday (July 21, 2012) I spent the day at a Windows 8 DevCamp, and had a lot of support from Microsoft starting to get our Travel Advisories App ported to Windows 8.

The app renders html using the WebView control, but in trying to port it, I ran into a number of problems.

The first problem I encountered was that there is no equivalent of the OnNavigating event, raised by the WP7 control.  In WP7, what we did was perform a WebBrowserTask.Show() on containing whatever page was being navigated to.

Launching the web browser wasn’t that great of an experience on Win 8 in any case, so I decided I’d put that on hold.  That’s when the second problem appeared.

We construct the first page shown in the app in memory, and then use NavigateToString.  Unfortunately, the page doesn’t appear to accept clicks or navigate reliably when you first navigate.  Resizing the app on Win8 appears to make the WebView finally show it’s scroll bars, and take navigation hits.  On that note, I took the train back to Cambridge.

This morning I had a few more ideas.  I thought, that since I can’t pop open a new web browser on navigate, I’d try to handle the navigation to a new page in the app.  I do this by using the LoadCompleted event.

Unfortunately, this event isn’t reliably raised on a new page, nor is the NavigationFailed event.

My plan was to keep a count of the number of times navigation occurred (assuming that none of the pages raise back by themselves), and then allow navigation back by executing a javascript expression “window.history.back();” depending on how many pages I’d navigated.

Unfortunately, while this occasionally works, it also occasionally throws an exception.

So, all in all, I think the message in all this is: If your app needs an HTML viewer, your in for a world of pain.  I don’t know if this will be resolved before Win8 ships, as apparently it’s RTM in just 8 days.

Caveat Coder!

Saturday, 14 July 2012

WP7 ScheduledActionService = Scheduled Crash!

I’ve been on the trail of an irreproducible bug for a couple of weeks now, described on the forums

In effect, what has been happening is that ScheduledActionService.Find is throwing an exception, but I wasn’t able to duplicate the fault in our program Terminator which shows sunrise and sunset times.

However, we’ve been trying to get rid of some other navigation bugs, and it struck me that this was probably another banging on the back key bug.

And it turned out I was right, that’s exactly what it was.  If you repeatedly stop and start our app (and probably any other app that refreshes a live tile on startup) you can provoke this failure.

It appears the crux of the problem is that the previous instance of the app has not quite completed when you launch the new instance.  If you get the timing exactly right, the call to ScheduledActionService.Find will throw, and if you're even more lucky you’ll catch it in the debugger, and see that immediately after it fails, it throws a ThreadAbortException

That’s a pretty good clue that there’s some internal bug that is triggered by the previous instance not having let go.

My solution?  Initially I thought wrapping a mutex around the whole program would do it, but it still failed.  That implies that the abort on the previous version released the mutex, but hadn’t yet cleaned up the remainder of the ScheduledActionService.

So the working solution is to retry the call to ScheduledActionService.Find up to three times, delaying 100ms each time, to let the previous instance shut down correctly and get out of the way.  Timing of course may vary depending on your app.

Wednesday, 4 July 2012

I really do hate hardware


Today one of my customers was trying to print with a Kodak ESP C310 printer and our program (http://www.wieser-software.com/payslips) crashed when calling a WPF 4.0 program's Print Dialog.

We installed the latest drivers, but the problem remained.


As a last ditch effort I selected "print directly to printer" on the preferences for the printer, and it worked, so it appears there's some incompatibility with the Kodak print spooler.

Thursday, 28 June 2012

Burnt by a faulty WPF install

Over the past couple of days, we’ve been trying to debug a problem reported by a customer of our WPF program, Payslips for PAYE Tools.

The customer was reporting that the program was crashing, and not generating any error reports (internally, we hook into the unhandled exception handler, and generate an email message containing the report, so we can examine the flaw).

Eventually after connecting to his machine remotely, we discovered that there were events in the event log, and they were TypeInitializationExceptions.

That exception is thrown when a static constructor fails for some reason.

Unfortunately, that implied that some of our static members were failing to initialize correctly.  So, we took the initialization and moved it into the instance constructor (as it was the App class), hooked up the error handler at the beginning of the class constructor, and crossed my fingers that it would catch the error.

But it didn’t work!  So I added a message box at the beginning of the class constructor.  That didn’t show either on the afflicted system.  With hundreds of working installs, it had to be something to do with the installation, so another connection to the remote PC was made, and we noticed that there were outstanding Windows updates for .NET 4.0

We left the customer to install them, but he told us that the updates also failed.

Eventually, he told us that the error messages led him to the .NET removal tool (link to follow).

We suggested that he should run that, reinstall our program, and let it download the .NET framework.

And what a surprise, our program now works correctly.

But what a horrible experience for the end user!  How does an install get into that state, and how can we diagnose it?

Sunday, 20 May 2012

More bugs in the Toolkit ListPicker

We recently updated our Chromatic Tuner app, Tune Up, and after the update using the latest fixes for the Silverlight Toolkit was disappointed to find some new stack traces on the control panel.

As usual it’s a navigation bug, this time caused by a storyboard completing after something else has happened, in this case, someone pressed the start button after the navigation began.

As a result, the code in PickerPage.xaml.cs calls NavigationService.GoBack(); in the OnNavigatedTo handler.

Then the storyboard completes, and NavigationService.GoBack(); is called again while navigating.  We all know this is going straight to the exception handler.

The fix and issue are at http://silverlight.codeplex.com/workitem/10769 but I’ll duplicate it here.

private void OnClosedStoryboardCompleted(object sender, EventArgs e)
{
// Close the picker page
if (NavigationService.CanGoBack)
{
// Only do this if we can go back, or we crash
// navigate to start menu before this happens provokes.
NavigationService.GoBack();
}
}



But wait, there’s more!


While trying to diagnose this problem, I was playing around with the ListPicker trying to figure out exactly what might be going on, and I found another problem.


Immediately after you make your selection, the transition begins, and effectively you’ve made your selection.


But it’s actually possible to click on another item, and select that during the transition!  I consider this undesirable behaviour too.  You made your choice, and the transition began, yet you can change it at the last minute?  BZZZZ.  Wrong.


Here’s the fix for that one, again in ListPickerPage.xaml.cs:


private void ClosePickerPage()
{
IsOpen = false;
// AAW: disable picker on exit.
Picker.IsEnabled = false;
}

Saturday, 19 May 2012

Don’t use NavigationOutTransition from the Toolkit

I’ve recently updated a bunch of our software at www.wieser-software.com/m and have been noticing while demonstrating it occasionally without a data connection, that it’s possible to end up with either a blank screen or two pages shown on top of each other as a result of navigation.

I think I’ve tracked it down to a bug in the Toolkit, though I can’t work out how to fix it.

The problem arises when you are transitioning away from a page with a NavigateOutTransition, and then end up navigating back into another page (maybe the same one) before that transition has been completed.

When this happens, your program will be unhappy.

The only way I’ve found for now to fix it is remove the NavigationOutTransition elements completely from my pages.

You can follow the issue here on the Silverlight Toolkit pages:

http://silverlight.codeplex.com/workitem/8293

Friday, 4 May 2012

One of our ListItems is missing! ListPicker Bug Alert!

I used the November ‘11 Silverlight Toolkit ListPicker control in one of my upcoming WP7 apps, and was surprised when impatiently, I started scrolling down while my full screen picker page was opening.

Unfortunately, when I got to the bottom of the page, some of the items were not visible, though vertical space was reserved for them.

Off to the source I went, and discovered that the ListPicker control initially sets every item on the page to be have a PlaneProjection with a RotationX of –90.  That would at least explain why my items weren’t visible.  They were rotated away from the field of view so they couldn’t be seen (Just like Calvin and Hobbes in 2D form)

So how did it happen?

Deep inside the ListPickerPage.xaml.cs file, in the UpdateVisualState function, there’s an IList<WeakReference> itemsInView that holds the list of items currently in view, then a few lines later, a Dispatcher.BeginInvoke on UpdateOutOfViewItems.

UpdateOutOfViewItems then collects the list of visible items again.  Only they might not be the same items.  In fact, any items that are new to the set will not be drawn correctly.

The Solution

The solution of course is to change the call to pass in the list of in-view items to the UpdateOutOfViewItems, changing the call to

Dispatcher.BeginInvoke(new Action(() => UpdateOutOfViewItems(itemsInView)));

and the signature to:

private void UpdateOutOfViewItems(IList<WeakReference> itemsInView)

and finally we don’t call GetItemsInViewPort in the UpdateOutOfViewItems.

I’ve added this fix as a hotfix to the SilverlightToolkit project here:

ListPickerPage.xaml.cs