Thursday, February 11, 2010

Force Internet Explore Emulation

Developing a completely flexible web application today can be tired-some,
And Microsoft sure doesnt make it any easier - a working site on IE8 could look bad on IE7, and might not work at all on IE6.

To make it a little bit easier, Microsoft enabled us to use "IE 7 Emulated Mode" on IE8, and luckily they made it possible for us to force IE8 to use Emulation.

Simply add:

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

to your header, and IE8 will automatically move to IE7 Emulation mode.

I know I know, it's an ugly workaround, but when you're deadline is yesterday, it might be just what you need...

Wednesday, August 5, 2009

Force Elavation By Code - Windows Vista & 7

If you want to force your application to run in elavated mode in Windows Vista or Windows 7, here's a quick guid on how to do it:

There's a Registry Key called:

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers


Under this key, there's a value for each applications on your computer configured
either to run in compatability mode (WINXP or other) or as administrator (using elavation).

In order to add your application to this list, you should do the following:
1. Create a new REG_SZ (string) Value named after your full application path, i.e:

C:\Program Files\Your App\App.exe


2. Edit the Value you just created with the following data:

RUNASADMIN


3. If you want to force your application to run not only in elavation, but in XP SP3 compatability mode, update your Value's data to the following:

WINXPSP3 RUNASADMIN


Note: After creating this Registry Value, you must restart your application.

And... That's it!

Friday, August 15, 2008

Cross Processing: #1 Accessing TextBox

So this is the first in a series of posts on accessing cross process UI data.

Note: This posts will correspond to windows-rendeder process windows, and not WPF or java applications that render differently.

Some Background
Buttons, Textboxs, ComboBoxs and the rest are all called "Controls", but they are all actually different forms of "Window"'s.

Every visual (unlike services) process in Windows, is basically a window heirarchy where the root window is the container (with the minimize,maximize and close buttons) and the rest are the actual controls.

The way each control (window) sends information to other controls is through a broadcast mechanism called "Window Messages".

Very much like processes, we could search for a specific window using its unique identifier - handle (like process id), and make less specific search using its name and class.

The demo will be to start the calc, and update and read its textbox.

Prerequisits:
Before we could start codeing, we need some win api declarations:

1. In order to get the handle of a certain window, we'll use FindWindowEx - a windows api declaration:


[DllImport("user32.dll")]
public static extern IntPtr FindWindowEx(IntPtr hwndParent, IntPtr hwndChildAfter, string lpszClass, string lpszWindow);



2. in order to send data to a window, we need to send it a message:


[DllImport("user32.dll")]
public static extern IntPtr SendMessage(IntPtr hWnd, uint Msg, int wParam, string lParam);


3. Get the buffer of the text:


[DllImport("user32.dll")]
public static extern int GetWindowTextLength(IntPtr hWnd);


4. Get the actual text:

[DllImport("user32.dll")]
public static extern int GetWindowText(IntPtr hWnd, StringBuilder lpString, int nMaxCount);



The Code!

Ok, so first we'll start the process:


Process proc = Process.Start(fullProcessPath);

proc.WaitForInputIdle();



Now, we'll use the FindWindowEx api to get the handle to its Edit box (the big textbox):


IntPtr hwnd = FindWindowEx(proc.MainWindowHandle, IntPtr.Zero, "Edit", "");



We have the control's handle, now we could...

1. Change value to "115":


SendMessage(hwnd, 0x000C, 0, "115");



2. Read the value:


int cap;
StringBuilder sb;
cap = Win32.GetWindowTextLength(this.Handle);
sb = new StringBuilder(cap + 1);
Win32.GetWindowText(this.Handle, sb, cap + 1);
return sb.ToString();

Sunday, June 3, 2007

Google Gear Vs. Web Browsers

A few days ago, Google released a beta (of course) version of a new open-source project called Gear.

Gear's main aim is to enabled online applications work offline as well.
Notice I didn't say web-based as the Gear API is open for RIA solutions as well - even more - Adobe's Apollo (Adobe's answer to WPF) project manager said it would have integrated support for the Gear API.

What Is This Gear Anyway?
Well its a very good question, since it's current release is really in its early beta stages and is probably due for some major changes, but its basically a browser plugin (currently supports only FireFox & IE under Window) which exposes a complete framework of utilities to store and retrieve... anything!
Whether it's image or script resources or applicative user-data - everything can be stored (per user of course) and retrieved easily like a hash map or using a simple ansi-sql like language!

This really sounds amazing, but what does this really means?
For the last decade or so, web browsers has become allot more that just an html engines, they now offer local cache, storing user-based data using cookies and saving your forms data.

But then Gear came.

But Why Is Gear Better Than My Existing Browser Solutions?

Because it does everything the browser does, only better.
Here's why:
1. Caching: Although client-side cache is a good thing, its one of the web-developer's worst nightmares - think of updating a script file and not knowing if your clients are using the new version, or the old and buggy one since their browser decided to store it.
Using Gear, you get the power to store resource files by version and retrieve them using a simple sql-like query or key-based!
You then not only don't have to worry if a new version is used or not, but you could also force a selected resource to be cached!

2. Cookies: Not only cookies have a limit on size and content data (cookies have a content security policy), but you don't know if cookies are enabled and if they do, if the client decided to delete them or not.
Using Gear you can save your data per-user using a secure manner, and retrieve no matter what browser your client uses.

There are many other reasons why Gear is good, but I haven't got to Gear's main goal - offline accessibility.

One of the biggest web-based mail client draw-backs is the necessity of being connected to the net.
Think of connection to your gmail or hotmail - for that matter - even while not connected to the net! or even better - to your online Google docs!

Summary
Gear is a set of client-side utilities that enable you to get a bigger handle on how and what data is stored on your client machine without worrying about his\hers browsers settings, allowing you to build a complete offline-accessible web-based solution!

Could this be a knockout to Web\RIA based solutions over the smart-client technologies?

Friday, March 30, 2007

A (Not So) New UI Front-End Alternative

When we're going to start a new project, we're accustomed to the standard 3-tier architecture, and although most of us will probably choose the same frameworks for our data and logic tiers, it's because these frameworks gives us everything we expect them to.

But what about our most important tier, the one that will make people buy our products - the UI tier? it looks like we don't have that kind of luxury of choosing a framework and we'll probably use ASP.Net.

And don't get me wrong - I really like ASP.Net and there are many splendid Ajax tool-kits\frameworks out-there that really are great,
But at the end of the day its basically HTML, and HTML is no fun - its too abstract, requires us to use Scripting languages which are hard to maintain and develop, not Object-Oriented, insecure, platform-dependent (each browser has its own engine) and many other cons.

So after cussing for a couple of days we'll probably use ASP.Net and be happy with it, because there is no other option...

Isn't there?


Adobe Flex Flash Developer
For most of us, Flash still sounds like a kids app for funny videos and games.
But apparently its a fully compliant Object-Oriented language!
So here are 3 facts you didn't know about flash:

1. Cross-Platform: Flash is supported for over 10 platforms amongst them are: Windows, Linux, Mac, Nokia (*), Solaris, Palm OS, BeOS and more.

2. Performance: From results of a benchmark done a few weeks ago, (See Benchmark Here) Flash is faster than Microsoft's new alternative - WPF\E, and on certain circumstances even faster than WPF!

3. IDE: Since mid 2004, Flash has a fully featured IDE based on the open-source Eclipse.

The most amazing thing about Flash is that it's absolutely server-side agnostic.
You could build a fully managed .Net back-end and connect your Flash GUI smoothly to it by WebServices or even directly call to your .Net methods.

Yep that's right using Macromedia's Remoting MX technology you can directly call your .Net methods from the flash code (Here's how)


Conclusion:
Before you start developing you next project, you should check reall good if ASP.Net is really the best way...