Here’s a good stackoverflow post about how to go about adding a menu item to you app’s system menu in .NET, the system menu is the one that pops down when you click on your app’s icon:
http://stackoverflow.com/questions/4615940/how-can-i-customize-the-system-menu-of-a-windows-form
Here is a good post about getting an Visual Studion Setup project to generate a .msi that will update a previous installation rather than demanding that the existing install be uninstalled before it can be reinstalled:
http://www.simple-talk.com/dotnet/visual-studio/updates-to-setup-projects
I followed the steps in the ‘How to update your product’ section.
The only catch is that the setup project will only update files that have had their version number changed even if the files them selves _have_ changed. To ensure that all files are included in the installation package, I had to make sure that all of the projects in my solution changed their version numbers on each build, to do this I edited each project’s AssemblyInfo.cs file and replaced:
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]
with:
[assembly: AssemblyVersion("1.0.*")]
//[assembly: AssemblyFileVersion("1.0.0.0")]
This causes a new version to be generated on each build and forces the set-up project to include them in the installation package!
On Monday Google announced that their cloud platform, Google App Engine now fully supports Python 2.7 which is great news!
More details can be found here:
http://googleappengine.blogspot.in/2012/02/announcing-general-availability-of.html
and here:
http://code.google.com/appengine/docs/python/python27/newin27.html
When using a db.ReferenceProperty in google app engine, the function get_value_for_datastore() can be used to get the key of a referenced datastore model without causing GAE to automatically fetch the model – this can be very handy if you are trying to optimise the performance of your cloud code.
from google.appengine.ext import db
class A(db.Model):
b = db.ReferenceProperty(B)
class B(db.Model):
name = db.StringProperty()
In the above code, A contains a reference to B, given a model of type A, b’s key can be retrieved as follows:
a = A().get_by_id(1234354)
b_key = A.b.get_value_for_datastore(a)
This will get b’s key without fetching its model!
In google app engine’s cloud based Datastore db.ReferenceProperty can be used in a Model to reference another Model like this:
from google.appengine.ext import db
class A(db.Model):
b = db.ReferenceProperty(B)
class B(db.Model):
name = db.StringProperty()
In the above example A references B, if you have an object of type A you can directly access its referenced B like this:
b_name = a.b.name
When you access a.b, GAE will automatically fetch b from the datastore without you having to do anything special. This is handy, but sometimes you may not want the automatic datastore fetch to happen, instead you may just want know the referenced object’s key.
If you were dealing with 1000s of objects, the extra DB fetch for each object could add a huge unnecessary time overhead to your processing (for example if you were using memcache for caching, or if you already had a list of all the relevant b’s in memory).
So how do we retrieve the key of the referenced object without triggering an datastore fetch? To achieve we have to invoke a rather obtuse function called (wait for it): get_value_for_datastore()
For example, We can find out what b’s key value is like this:
b_key = A.b.get_value_for_datastore(a)
The above won’t cause GAE to fetch the referenced B from the datastore. Its all a bit long winded and confusing but it does seem to work!
I gave a talk some time ago to the Google Users Group in Dublin about how to go about coding up the the integration of paypal redirect payments into a Google App Application with python, if anybody’s intersted the talk slides are here:
In summary its possible and not that difficult!
If you are trying to use a cheeky file static or global variable while eagerly developing your C++/CLI software you will probably encounter the following error:
“C3145, global or static variable may not have managed type”
At this point you remember that this isn’t really C++ but a crazy non-standard extension to C++! So instead of declaring a file static scope variable like this:
static Acquisition::IImage^ simage = nullptr;
So as a fix, you can declare a container class and add it as a static member, thus:
ref class ImageContainer {
public:
static Acquisition::IImage^ Image = nullptr;
};
And then access it in this way:
ImageContainer::Image = image;
Thus solution worked well for us, but of course we will be getting rid of this global variable in due time! ;)
Q: How can I stop BitmapImage, in .NET Windows Presentation Foundation (WPF) from locking the source image file?
A: By default BitmapInfo seems to lock the source image file so that you can use the bitmapinfo object and modify or delete the source file at the same (or similar) time. For example, this C# will probably yield a locked image file:
var bitmap = new BitmapImage(new Uri(imageFilePath));
// use bitmap...
You can get around this locking problem as follows, it’s a little bit more long-winded but it worked for us….
var bitmap = new BitmapImage();
var stream = File.OpenRead(imageFilePath);
bitmap.BeginInit();
bitmap.CacheOption = BitmapCacheOption.OnLoad;
bitmap.StreamSource = stream;
bitmap.EndInit();
stream.Close();
stream.Dispose();
// Use bitmap.....
.NET’s Threading module isn’t the best, it has the look of a model that was designed by the type of software people who like to keep practical multi-threading a good long arm’s length away. It’s workable but sometimes it requires that you jump through hoops to do simple everyday things with threads – like updating a UI element from a non UI thread etc. You may see errors akin to the following:
“Must create DependencySource on same Thread as the DependencyObject.”
“This type of CollectionView does not support changes to its SourceCollection from a thread different from the Dispatcher thread.”
To get around this all a .NET developer needs to do is to remember a few ritualistic looking invocations to appease the .NET small gods – but of course I can never remember the details so am recording one such here:
To dispatch to the UI from a non-UI thread and non-UI code, use something like the following:
using System.Windows; Application.Current.Dispatcher.Invoke(new Action (() => Thumbnails.Add(thumbnail)));
In WPF when you try to assign a bitmap to a property that’s bound to a UI element from a worker thread you may get the following error:
“Must create DependencySource on same Thread as the DependencyObject”
A simple way around this problem without having to jump through hoops and dispatch to the UI thread is to just freeze the bitmap before assigning it, like this:
var bitmap = new BitmapImage(new Uri(CurrentImageFilePath));
bitmap.Freeze();
this.CurrentImage = bitmap;
I hope this helps someone who’s stuck with this annoying error!
Address: 43 Churchgate, Wicklow, Co. Wicklow, Ireland.
Telephone: +353 87 2236429
email: info@ridgesolutions.ie