The newest addition to the Microsoft Visual Studio family is Lightswitch - a new take on the IDE allowing business applications to be built faster than ever. Lightswitch uses the model of such applications being based on data tables and screens, and the provision of standard functionality (e.g. field validation) that developers spend countless hours rewriting every time, to speed up the development process.
Aside from the standard functionality provided, customisation (e.g. custom validations) is possible using the normal C# or Visual Basic code we are all used to. Additionally, the look and feel of applications can be changed through a simple dropdown box, and may be adjusted on the fly even while debugging applications.
The Lightswitch website provides information, screenshots and videos on what Lightswitch is all about. The Lightswitch Developer Center provides several resources to get started, including a download of the beta itself.
Actually getting up and running with the Lightswitch beta can be a bit tricky. Paul Patterson's blog post goes through the difficulties encountered in setting up Lightswitch. A forum post deals with removing WCF RIA Services for Visual Studio 2010 through the registry (since the uninstall does not actually cleanly remove it), which is necessary before installing the Lightswitch beta.
Saturday, February 26, 2011
Tuesday, February 15, 2011
Adjusting Ubuntu resolution in VirtualBox
I had a problem when installing an Ubuntu 10.10 image in VirtualBox because the screen resolution was remaining at a tiny 800x600, barely allowing room for a single terminal window.
The following commands install the guest additions which are necessary for running Ubuntu at full resolution:
sudo apt-get update
sudo apt-get install build-essential linux-headers-$(uname -r)
Thanks goes to Gilbert Galea for providing the above solution.
The following commands install the guest additions which are necessary for running Ubuntu at full resolution:
sudo apt-get update
sudo apt-get install build-essential linux-headers-$(uname -r)
sudo apt-get install virtualbox-ose-guest-X11
Thanks goes to Gilbert Galea for providing the above solution.
Saturday, November 27, 2010
SDL Quickstart for Linux: Empty Window
This short tutorial explains how to get started with SDL on Linux, by showing an empty Window. Once this is set up, you can go on to create 2D games or use SDL as a basis for OpenGL.
This tutorial is loosely based on Lazy Foo's "Getting an Image on the Screen" tutorial, but is intended to be more concise, link to reference material, apply directly to Linux, and teach additional items learned through experience.
Setting up
First of all you need to have the SDL development and runtime libraries installed on your system. You can find the SDL-related libraries using the command
This will give you a whole list of libraries. At the time of writing of this tutorial, the one you need is libsdl1.2-dev. Therefore, on Ubuntu or similar Debian-based Linux distributions, you would install SDL using the command:
This will install the header files in /usr/include/SDL/ and also the shared libraries you need to run SDL applications (similar to the SDL.dll you need on Windows).
First SDL Application: Empty Window
Like with any C program, you start with a main() function and any necessary header inclusions. For SDL applications you need to include the SDL.h file, which contains all the functionality you will need:
In SDL programs, it is necessary to declare the main() function with arguments, as above. I have experienced errors in the past when compiling SDL programs with a main() function that did not account for command line parameter arguments (argc and argv).
The next step is to initialise the SDL library, and also prepare the cleanup function while you're at it. Other program code will go in between.
SDL_Init is the function that initialises SDL. As a parameter, it takes a number of flags which tell it what to initialise. Multiple flags may be used at once by using the bitwise OR operator (e.g. SDL_INIT_VIDEO | SDL_INIT_AUDIO). Although Lazy Foo's tutorial simply initialises everything, all you need for this simple tutorial is video display functionality.
SDL_Quit is a cleanup routine that you should use at the end of your SDL code, to free resources allocated by SDL_Init.
Between SDL_Init and SDL_Quit, you can now show your window. First declare relevant variables:
Then actually show the screen, and clean up after. Program code will go in between.
SDL_SetVideoMode displays a window with the given parameters. SDL has the limitation that only one window can be displayed at any given time, so calling this function again will result in a new window drawn instead of the first one. As parameters, SDL_SetVideoMode takes the width and height of the window (in pixels), the bits per pixel (32 on modern systems - this is a measure of the graphical quality used) and a set of flags (refer to the function's documentation via the link). For the purpose of displaying something simple, you can use the SDL_SWSURFACE flag; however for complex applications such as OpenGL you will need to use more advanced options to optimise your program.
Handling the "X" to close the window
If you run your program now, a window will flash briefly on the screen and then disappear. This is because you are showing the window but have no code in place to keep it there. Lazy Foo's tutorial uses SDL_Delay to delay the disappearance of the window.
A better way is to handle events - something you will need to do anyway in your program. Games and other graphical applications generally run a game loop, i.e. they will keep running until something happens (e.g. you quit the game). In this case we want to handle the "X" at the top of the window, so that when a user clicks on it, the window closes - but otherwise the window remains. The following code will do the trick::
The code above runs the game loop, i.e. the window will remain visible as long as quit is zero. Using SDL_WaitEvent, the program sits idle until something happens. In this case we are taking action when the event is SDL_QUIT, i.e. the close-window "X" button has been clicked. At that point we set quit to one and let the program exit.
Interactive applications such as games normally use SDL_PollEvent to constantly check for events and update the game state. However, this is very CPU intensive, and for something as simple as this, SDL_WaitEvent is a better alternative. Note: SDL_PollEvent can be combined with a small SDL_Delay to reduce the burden on CPU.
Compile and run
Save the code in a file called main.c. From your terminal, use the following command to compile your SDL application:
Run ./app to launch the application.
Full code (main.c)
This tutorial is loosely based on Lazy Foo's "Getting an Image on the Screen" tutorial, but is intended to be more concise, link to reference material, apply directly to Linux, and teach additional items learned through experience.
Setting up
First of all you need to have the SDL development and runtime libraries installed on your system. You can find the SDL-related libraries using the command
apt-cache search sdl
This will give you a whole list of libraries. At the time of writing of this tutorial, the one you need is libsdl1.2-dev. Therefore, on Ubuntu or similar Debian-based Linux distributions, you would install SDL using the command:
sudo apt-get install libsdl1.2-dev
This will install the header files in /usr/include/SDL/ and also the shared libraries you need to run SDL applications (similar to the SDL.dll you need on Windows).
First SDL Application: Empty Window
Like with any C program, you start with a main() function and any necessary header inclusions. For SDL applications you need to include the SDL.h file, which contains all the functionality you will need:
#include <SDL/SDL.h>
int main(int argc, char * argv[])
{
int main(int argc, char * argv[])
{
return 0;
}
}
In SDL programs, it is necessary to declare the main() function with arguments, as above. I have experienced errors in the past when compiling SDL programs with a main() function that did not account for command line parameter arguments (argc and argv).
The next step is to initialise the SDL library, and also prepare the cleanup function while you're at it. Other program code will go in between.
SDL_Init(SDL_INIT_VIDEO);
// other program code goes here
SDL_Quit();
SDL_Init is the function that initialises SDL. As a parameter, it takes a number of flags which tell it what to initialise. Multiple flags may be used at once by using the bitwise OR operator (e.g. SDL_INIT_VIDEO | SDL_INIT_AUDIO). Although Lazy Foo's tutorial simply initialises everything, all you need for this simple tutorial is video display functionality.
SDL_Quit is a cleanup routine that you should use at the end of your SDL code, to free resources allocated by SDL_Init.
Between SDL_Init and SDL_Quit, you can now show your window. First declare relevant variables:
int width = 640;
int height = 480;
int bpp = 32;
Uint32 flags = SDL_SWSURFACE;
int height = 480;
int bpp = 32;
Uint32 flags = SDL_SWSURFACE;
SDL_Surface * screen = NULL;
Then actually show the screen, and clean up after. Program code will go in between.
screen = SDL_SetVideoMode(width, height, bpp, flags);
// program code goes here
SDL_FreeSurface(screen);
SDL_SetVideoMode displays a window with the given parameters. SDL has the limitation that only one window can be displayed at any given time, so calling this function again will result in a new window drawn instead of the first one. As parameters, SDL_SetVideoMode takes the width and height of the window (in pixels), the bits per pixel (32 on modern systems - this is a measure of the graphical quality used) and a set of flags (refer to the function's documentation via the link). For the purpose of displaying something simple, you can use the SDL_SWSURFACE flag; however for complex applications such as OpenGL you will need to use more advanced options to optimise your program.
Handling the "X" to close the window
If you run your program now, a window will flash briefly on the screen and then disappear. This is because you are showing the window but have no code in place to keep it there. Lazy Foo's tutorial uses SDL_Delay to delay the disappearance of the window.
A better way is to handle events - something you will need to do anyway in your program. Games and other graphical applications generally run a game loop, i.e. they will keep running until something happens (e.g. you quit the game). In this case we want to handle the "X" at the top of the window, so that when a user clicks on it, the window closes - but otherwise the window remains. The following code will do the trick::
int quit = 0;
SDL_Event event;
while (quit == 0)
{
SDL_WaitEvent(&event);
switch(event.type)
{
case SDL_QUIT:
quit = 1;
}
}
{
SDL_WaitEvent(&event);
switch(event.type)
{
case SDL_QUIT:
quit = 1;
}
}
The code above runs the game loop, i.e. the window will remain visible as long as quit is zero. Using SDL_WaitEvent, the program sits idle until something happens. In this case we are taking action when the event is SDL_QUIT, i.e. the close-window "X" button has been clicked. At that point we set quit to one and let the program exit.
Interactive applications such as games normally use SDL_PollEvent to constantly check for events and update the game state. However, this is very CPU intensive, and for something as simple as this, SDL_WaitEvent is a better alternative. Note: SDL_PollEvent can be combined with a small SDL_Delay to reduce the burden on CPU.
Compile and run
Save the code in a file called main.c. From your terminal, use the following command to compile your SDL application:
gcc main.c -lSDLmain -lSDL -o app
Run ./app to launch the application.
Full code (main.c)
#include <SDL/SDL.h> int main(int argc, char * argv[]) { int width = 640; int height = 480; int bpp = 32; Uint32 flags = SDL_SWSURFACE; SDL_Event event; int quit = 0; SDL_Surface * screen = NULL; SDL_Init(SDL_INIT_VIDEO); screen = SDL_SetVideoMode(width, height, bpp, flags); while (quit == 0) { SDL_WaitEvent(&event); switch(event.type) { case SDL_QUIT: quit = 1; } } SDL_FreeSurface(screen); SDL_Quit(); return 0; }
Sunday, November 14, 2010
Legacy icons in Windows XP
When your computer is a bit busy, you might notice something like this while Windows Media Player is loading:

The icons in the upper right hand corner show while it is busy loading. A similarly dated prompt appears when there is an error accessing your CD or DVD drive:

Notice that this prompt does not use the Windows XP styles.
I have always thought that this is because the XP visuals are simply a layer over Windows 3.1 or Windows 2000 functionality. If a window gets stuck (as in the Windows Media Player example) then you can see the old layout before the XP one is rendered over it. This is obviously a waste of performance.
On the other hand, I think the CD/DVD error was simply forgotten and left as it was.

The icons in the upper right hand corner show while it is busy loading. A similarly dated prompt appears when there is an error accessing your CD or DVD drive:

Notice that this prompt does not use the Windows XP styles.
I have always thought that this is because the XP visuals are simply a layer over Windows 3.1 or Windows 2000 functionality. If a window gets stuck (as in the Windows Media Player example) then you can see the old layout before the XP one is rendered over it. This is obviously a waste of performance.
On the other hand, I think the CD/DVD error was simply forgotten and left as it was.
Tuesday, October 26, 2010
LaTeX: MiKTeX undefined references
For the past three days I tried to get started with LaTeX on Windows. Using MiKTeX, I ended up in a situation where (a) my bibliography wasn't showing at all, (b) citations showed up as [?], and (c) the log complained about undefined references.
It turned out that the errors were obscure and unrelated to the cause. The references and citations were fine; it was the bibliography style that was incorrect. It needs to be like this to work:
\bibliographystyle{plain}
\bibliography{mybib}
\nocite{*}
You need to use \bibliographystyle and not \bibstyle that appears on some websites. The style needs to exist or it will not work. The bibliography file specified must be without the .bib extension. \nocite{*} is optional and makes LaTeX include references even if they are not cited.
Also, you may need to compile two or three times for the references to be properly linked.
It turned out that the errors were obscure and unrelated to the cause. The references and citations were fine; it was the bibliography style that was incorrect. It needs to be like this to work:
\bibliographystyle{plain}
\bibliography{mybib}
\nocite{*}
You need to use \bibliographystyle and not \bibstyle that appears on some websites. The style needs to exist or it will not work. The bibliography file specified must be without the .bib extension. \nocite{*} is optional and makes LaTeX include references even if they are not cited.
Also, you may need to compile two or three times for the references to be properly linked.
Saturday, October 16, 2010
inet_ntoa() segmentation fault issue
inet_ntoa is a UNIX system call used in socket programming to obtain an IPv4 string form of an IP address from its in_addr form.
I have encountered an issue where its use results in the following warning:
warning: assignment makes pointer from integer without a cast
Attempting to run a program with this warning on inet_ntoa will result in a segmentation fault.
The cause of the problem is not incorrect C, but a missing header file. Shachar Shemesh wrote that the solution to this obscure problem is simply to include the arpa/inet.h header file:
#include <arpa/inet.h>
I have encountered an issue where its use results in the following warning:
warning: assignment makes pointer from integer without a cast
Attempting to run a program with this warning on inet_ntoa will result in a segmentation fault.
The cause of the problem is not incorrect C, but a missing header file. Shachar Shemesh wrote that the solution to this obscure problem is simply to include the arpa/inet.h header file:
#include <arpa/inet.h>
Saturday, September 4, 2010
Errors: helpful vs useless
Today I tried to install the Windows Phone 7 Developer Tools beta, and was given this lovely error message while the setup tried to start:
Thanks. What problem? Why? What can I do about it?
This really sounds like the installer crashed and there is no reason why - as if the developer just put a try..catch block to catch any kind of problem regardless of what the problem is. The downside is that the end user sees a problem and has no clue what happened.
The least you could do as a developer is put an error number. The user does not know what this means, but it gives him room to (a) ask the developer what went wrong, or (b) Google it, knowing that other users definitely ran into it and posted about it somewhere.
The best way to show errors, though is to do it in a way that is indicative of (a) what exactly went wrong (e.g. SQL error -264), (b) where it went wrong (e.g. function name), and (c) what the user can do about it (e.g. contact customer support, read some FAQ, configure a setting, etc).
This is informative for the user (who knows what went wrong and what action to take) and also for the developer (who can debug the software if necessary and trace the source of the problem).
Thanks. What problem? Why? What can I do about it?
This really sounds like the installer crashed and there is no reason why - as if the developer just put a try..catch block to catch any kind of problem regardless of what the problem is. The downside is that the end user sees a problem and has no clue what happened.
The least you could do as a developer is put an error number. The user does not know what this means, but it gives him room to (a) ask the developer what went wrong, or (b) Google it, knowing that other users definitely ran into it and posted about it somewhere.
The best way to show errors, though is to do it in a way that is indicative of (a) what exactly went wrong (e.g. SQL error -264), (b) where it went wrong (e.g. function name), and (c) what the user can do about it (e.g. contact customer support, read some FAQ, configure a setting, etc).
This is informative for the user (who knows what went wrong and what action to take) and also for the developer (who can debug the software if necessary and trace the source of the problem).
Subscribe to:
Posts (Atom)