Strange case of the displaced Combo Box dropdown

I was adding a User Login window for a WPF application in a project that uses Caliburn.Micro. This Window was opened during the Caliburn.Micro OnViewLoaded event and included a ComboBox for user name selection.

Everything worked as expected (though the User Login window appeared before the main view was displayed). However, when the ComboBox was clicked to display the dropdown list of user names the list appeared in the upper left of the screen.

A search showed that this was a known problem and much discussed with some solutions and suggestions. None that I found were specific to working with Caliburn.Micro but this reply on StackOverflow by Ken Salter was enough to provide a succint solution to the problem: http://stackoverflow.com/questions/1998024/wpf-combobox-dropdown-part-appears-in-the-wrong-place

I adapted the code to work in the OnViewLoaded event and this fixed the problem. The ComboBox worked as expected, plus the User Login window appeared after the Main View was displayed.

The code:

              private Dispatcher _dispatcher = Dispatcher.CurrentDispatcher;
        private delegate void DelegateOpenWindow();
        private DelegateOpenWindow _delegateOpenUsersWindow;
 
        protected override void OnViewLoaded(object view)
        {
            base.OnViewLoaded(view);
            _delegateOpenUsersWindow = (ShowUserSelectWindow);
            _dispatcher.BeginInvoke(_delegateOpenUsersWindow);
        }
 
        private void ShowUserSelectWindow()
        {
            dynamic usersWindow = new ExpandoObject();
            usersWindow.WindowStartupLocation = WindowStartupLocation.CenterOwner;
            usersWindow.WindowStyle = WindowStyle.SingleBorderWindow;
            WindowManager.ShowDialog(new UsersViewModel(Events, WindowManager), null, usersWindow);
        }

Dispatcher is provided by the System.Windows.Threading library:

using System.Windows.Threading;

ShowUserSelectWindow is the method I have used to show the User LogIn window (named UsersViewModel). The Delegate and Dispatcher items are directly adapated from Ken Salters example.

Interestingly, one of the discussions included a comment from a Microsoft person where they said this bug would be fixed in .NET 4.5. My project is targetted at .NET 4.5, in VS2013 – Caliburn.Micro is version 1.5.2.0.

No doubt the code could be simplified further and perhaps Async / Await could be used – though I haven’t experimented with that yet.

Some further links on this subject:

http://stackoverflow.com/questions/4677701/c-sharp-strange-wpf-combobox-behavior

http://social.msdn.microsoft.com/forums/wpapps/en-us/545461b5-cf62-48e2-bcfb-2e872ecea639/wpf-tooltips-and-comboboxes-are-in-top-left-corner (the last post is the one that claims it is fixed in .NET 4.5).

https://www.devexpress.com/Support/Center/Question/Details/B202426

 

 

 


 

Advertisements

Installing xUnitContrib Test Runner in VS2008

I use xUnit.net as my main test framework for a range of C# projects, including one in VS2008. This project is for a Windows Mobile 6.5 application and so can’t be moved on to Visual Studio 2010 / 2012 / 2013.

With the new Extension Manager in ReSharper (NuGet) it is easy to install the latest xunitcontrib update (called xUnit.net Test Support in the NuGet listing) into Visual Studio 2010 / 2012 and 2013. However, it is slightly more problematic to install into VS2008. Matt Ellis (Author of xunitcontrib) does supply a batch file to install but this sometimes lags behind the main release via NuGet.

On both the R# 8.0 and 8.1 releases I found that the following worked on my system (Win 7, 64 bit):

  1. Update ReSharper for all versions of Visual Studio.
  2. Update xUnit.net Test Support via the ReSharper Extension Manager in VS2012 (my other main dev environment).
  3. Find the location of the newest xunitcontrib.runner libraries – in my setup they are here (for R# 8.1): C:\Users\<username>\AppData\Local\JetBrains\ReSharper\vAny\packages\xunitcontrib.1.3.0\ReSharper\v8.1\plugins\xunitcontrib.runner.resharper.runner.8.1.dll
  4. I then copy the entire plugins folder to: C:\Program Files (x86)\JetBrains\ReSharper\v8.1\Bin\  .  Both times I have used this method the plugins folder didn’t exist so it was just a clean copy. If it does exist then copy the contents of the original plugins folder (step 3) into the existing one.
  5. Start VS2008 and open your test project – the tests should be marked and ready to work with as expected.

So far, I haven’t encountered any problems using this method and it follows the guidelines given by Matt for installing earlier versions of xunitcontrib.

For more information on the xUnit test runner: xunit.net contrib web site.

Zapped to infinity!

In my last post I’d described my initial set up of Zapier to “synchronise” my Trello and BitBucket systems.

I defined 4 Zaps that seemed to provide the functionality I needed to test Zapier at this point:

  1. When I Open an Issue in BitBucket then Zapier will Create a Card under my Backlog list in my Trello Board.
  2. When I Create a Card in the Backlog list in my Trello board, Zapier will Open an Issue in BitBucket.
  3. When I Create a new Repository in BitBucket the Zapier will Create a New Board in Trello.
  4. When I Push to BitBucket then my Changesets are logged as cards into a BitBucket Log list in my Trello Board.

(Note: All list names in Trello are the ones I use – yours are likely to be different!).

All tested as expected. HOWEVER, the eagle eyed amongst may have spotted the problem – I did leave it as it was initially set up to see if Zapier was intelligent enough to work around the problem (It wasn’t but can be told how to!).

The problem: Zaps 1 and 2 form an infinite loop. This is exactly what happened:  I created new Backlog card in Trello, a few minutes later Zapier Opened the Issue in BitBucket, a few minutes later Zapier Created a new Card from the new Issue and a few minutes later Opened a new Issue in BitBucket….. I let it run for 7 iterations then switched the Zap off.

I contacted Zapier about this and they answered within their stated time scale (a couple of hours, more on their support below). However, by that time I’d worked out the method to avoid the loop! Zapier comes with a rich set of Filters for each service it connects and using these avoids infinite loops or Zap duplication. This is where having a separate Zapier BitBucket account is very useful (though not essential).

The “BitBucket Open Issue to Trello Create Card” filter:

In Section (4) of the Zap edit (Filter BitBucket Triggers) I used the Custom Filters to create a single filter that would avoid any issues opened by my “Zapier” BitBucket account.

The left hand drop down provides a list of BitBucket fields that can be used – I selected reported_by_first_name, then set the middle filter action to (Text) Does not contain and entered the value Zapier in the data field (right most).

Filter used for BitBucket to Trello Zap

Filter used for BitBucket to Trello Zap

This passed the test and now works only when a BitBucket Issue is opened by someone other than “Zapier”!

The “Trello Create Card to BitBucket Open Issue” filter:

This needs a slightly different approach to the previous filter because there is no Zapier Trello user to identify the source of the Card. However, it is easy to add an identifier to the data that is passed via Zapier. This must be done in the “Open BitBucket Issue to Trello Card” Zap – the same one as used to set the filter above.

So I select that Zap for Edit and move down to section 5: Match up BitBucket Issue to Trello Card. Below the Board and List selection boxes are the Name and Description fields.

Zap-BBtoTrelloData

In the Description field I have used the Issue Content (a selectable BitBucket data field) and have also added a literal (Via Zapier) text indicator. This serves to:

  1. show that the card came from BitBucket via Zapier.
  2. act as a filter item to prevent the card getting Zapped back to BitBucket.

This tested ok and teh Zap switched on. This completes the changes needed to the BitBucket Issue to Trello Card Zap.

The next stage is to add the filter to the Trello Card to Bitbucket Open Issue Zap. Edit the Zap and move to section 4: Filter Trello Triggers.

The left hand drop down provides a list of Trello fields that can be used – I selected desc, then set the middle filter action to (Text) Does not contain and entered the value Zapier in the data field (right most).

Zap-TrellotoBBFilter

And that’s it! Test again and switch on the Zap. And it works like a dream! No more infinite loop.

And, as these things tend to happen, after I’d set it up and got it all working I got a detailed reply from Zapier support with the following:

If you want those zaps to work the way you intended but without the duplicates, we put together a guide that lets you use filters and a slight adjustment to how you create those cards/issues to avoid that loop: https://zapier.com/help/avoiding-zap-loops/

The Push to Bitbucket creates new Trello card Zap.

I think this is really good. I push changes to my BitBucket repo and some minutes later a new card appears in my Trello Board BitBucket Log list with the Revision number and Date and Time. There are more details within the card – but this allows a really good overview of the project progress within Trello (a single point of reference).

TrelloPushLogCard

I suspect I am only just at the very beginning of finding all the features and uses of Zapier. But, so far, it is proving its value.

Getting Zapped – or how to get Trello and BitBucket to talk

I have been using BitBucket for over 4 years as my main Source Control host for a variety of software and related projects. I use Mercurial as the actual Source Control system. The BitBucket/Mercurial combination has served (and continues to serve) my needs very well – especially as it is free for the number of users I have accessing it.

I also use Trello as a project management tool (again, it’s free at its “basic” level). This has proven to be an excellent tool for working with projects – using an on-screen equivalent of the project board and cards (or stickit notes) it is remarkably easy to set-up, maintain and update as a project progresses.

I found that I had all my Project details and cards/issues in Trello and nothing logged in BitBucket – nothing wrong with that, of course, but it would be good to have something that allowed issues to be tracked in BitBucket as I added them to Trello. A quick search of the web showed a couple of projects that “may come to something – eventually” and API information for BitBucket and Trello (but I don’t have time to work on these). It also turned up Zapier – the only connection service I could find that linked BitBucket and Trello. Plus points to Zapier for this.

As Zapier offer a 14 day trial I decided to try the service. This just involved the usual just sign up (email and password) and NO need for credit card details (another plus point!).

Creating Zaps (or connections – I’m surprised they didn’t call them Zapps!) is straightforward and you are guided through the process in a series of prompts and drop-downs. There are, however, a couple of considerations in the BitBucket / Trello connection that I’ll mention here:

Prepare a new BitBucket user: This is not essential but does allow you to track where BitBucket Issues are coming from. It is recommended when you get to the relevant point in creating your Zap.

I created a new user email under my web domain account (just zapier@<domian.com>). I then invited this new user to join BitBucket (earns me an extra user!) and created a new account under BitBucket for this user (I needed to open a different browser – Internet Explorer rather than FireFox because Firefox provided details of my existing main account and the new user account wasn’t created. I guess you could use a separate computer to achive the same result). Once I had created the new BitBucket account (new user name and password – keep to use in Zapier) I added the “Zapier” user to my project in BitBucket. All well to this point and I was ready to create my first Zap – which would copy any new issue in BitBucket to a Backlog list in Trello. I’ve described the process below:

  • In Zapier Select: Make a Zap
  • Then select BitBucket as the Trigger Service and Trello as the Action Service.
  • Select New Issue under Choose a Trigger and Create Card under Choose an Action then press Continue.
  • You are then asked to provide your BitBucket Account details (name and password) – use the “Zapier” one and then Test. All being well it will connect and pass the test.
  • The Trello connection was easier – just had the Allow this connection confirmation from Trello and it was done.
  • From this point on you make the connections between items and the data you want to be copied. All guided by drop-down boxes with available options – these let you select your Trello Board and your List for the Issue – there are more filters which allow more powerful selection of what is provided.
  • Once everything it set up you can test using some data that Zapier extracts from your BitBucket Issues. This does create new cards in your Trello list but shows that everything is working as expected.

First impressions are that this is an efficient and useful service – there are, of course, areas that could be extended. I will blog more about these as I work with the system.