There is a problem with the Modal Popup control in the AJAX .NET Control Toolkit. The fix is not documented very well.
When the popup is shown, you can drag it around in the browser window if you specified its "PopupDragHandleControlID" in your code. However, when you release your mouse button, the poup box moves back to its original position automatically, --with animation, too!
It turns out that in their example, they added a piece of javascript to fix just this problem. The function is called "setBodyHeightToContentHeight", and it is specifed as a window resize handler. Even though the window is not resized when you move your popup box in the browser window, this will fix your problem.
Thursday, June 3, 2010
Monday, April 12, 2010
The End of Load-Store Computing Is Coming
It is in the news that HP scientists is getting close to be able to produce devices based on memory resistors. One of them, Stan Williams, claims that we will see devices based on memory resistors working better than current NAND based devices in three years.
This is the beginning of a revolution. Besides the fact that memory resistors may potentially be used as more than just storage devices, fast static memory will change how computer software operate.
Currently, all application software, even including operating system and hardware drivers, follow a "load - execute - store" model. Data is loaded from permanent storage into RAM, processed, and then stored back to permanent storage. Faster static memory will make this model obsolete. A new model should be a "go to - execute" model. Nothing needs to be loaded. Software can execute exactly where it is stored because there will be no such thing as RAM anymore. Results need not be stored, because the results are already stored where they are in memory!
Because so much of our current software manage the load - store process of data, a new generation of software simply using "go to" without load/store will be needed to efficiently utilize the new hardware. All OS's, such as UNIX, LINUX, and Windows will all need to be re-written. After that, we will look back at the current "load - store" model software age as the "stone age".
Of course, some moving around of data will still be necessary from time to time, and data access to slow legacy storage will still need to follow the old model, at least partially. But that is different from the way things are now because to the new computers, connections to these devices will be treated almost like the way current computers handle phone dial-up modem connections. These devices can be "memory-mapped", but they are essentially "shadowed" with local static memory. So the loading process become a "shadowing process".
This is the beginning of a revolution. Besides the fact that memory resistors may potentially be used as more than just storage devices, fast static memory will change how computer software operate.
Currently, all application software, even including operating system and hardware drivers, follow a "load - execute - store" model. Data is loaded from permanent storage into RAM, processed, and then stored back to permanent storage. Faster static memory will make this model obsolete. A new model should be a "go to - execute" model. Nothing needs to be loaded. Software can execute exactly where it is stored because there will be no such thing as RAM anymore. Results need not be stored, because the results are already stored where they are in memory!
Because so much of our current software manage the load - store process of data, a new generation of software simply using "go to" without load/store will be needed to efficiently utilize the new hardware. All OS's, such as UNIX, LINUX, and Windows will all need to be re-written. After that, we will look back at the current "load - store" model software age as the "stone age".
Of course, some moving around of data will still be necessary from time to time, and data access to slow legacy storage will still need to follow the old model, at least partially. But that is different from the way things are now because to the new computers, connections to these devices will be treated almost like the way current computers handle phone dial-up modem connections. These devices can be "memory-mapped", but they are essentially "shadowed" with local static memory. So the loading process become a "shadowing process".
Wednesday, April 7, 2010
WCF with MSMQ
WCF over MSMQ can be difficult to setup. There are just too many layers. Frankly, in my opinion, it would be easier to implement fail over mechanisms without so may layers. Without all these extra layers, the chances of failures would be reduced, and the need for fail over is smaller at the first place.
When MSMQ throws an exception, the WCF host goes into a faulted state. You must handle the "Faulted" event of the service host in order to get any information on the fault. Without such an event handler, the service host just sits there quietly, as if there is nothing wrong. It will not handle any messages, and it will not give you any indication whatsoever that something is wrong.
Even if you do handle this event, there is little can be learned other than the service host entered faulted state. If you are lucky and you are in a debugger, you will see the exception that MSMQ threw, otherwise there is no way to retrieve the exception, especially if the service host runs in a service application.
One common MSMQ exception is that "An error occurred while receiving a message from the queue: The transaction specified cannot be imported. (-1072824242, 0xc00e004e). Ensure that MSMQ is installed and running. Make sure the queue is available to receive from." The error code is MQ_ERROR_TRANSACTION_IMPORT (0xC00E004E), which typically means that the transaction coordinator is not available. It turns out that you would have to allow MSDTC on the service host machine to access the network if the queue is not local.
Turning on network access for MSDTC requires the use of some tools. They are hidden at some not-so-obvious places: you would have to run dcomcnfg, open "Component Services". In some versions of Windows "Component Services" is on the "Administrative Tools" menu, but in some other versions, it is not.
Once you have found "Component Services", you need to go to the properties dialog box of "My Computer". On the "MSDTC" tab, check "Use local coordinator".
We are not done. Under "My Computer" in "Component Services", go to "Distributed Transaction Coordinator", "Local DTC", and go to its properties dialog box. Go to the security tab, and check "Network DTC Access".
All this is too complicated to maintain for a simple WCF service, not to mention the security implications. If you really love MSMQ so much that you have to have it, then this would get it to work. But WCF can work with simpler protocols. These simpler protocols are more reliable and more secure. After all, what MSMQ does is simple, we can live without it.
When MSMQ throws an exception, the WCF host goes into a faulted state. You must handle the "Faulted" event of the service host in order to get any information on the fault. Without such an event handler, the service host just sits there quietly, as if there is nothing wrong. It will not handle any messages, and it will not give you any indication whatsoever that something is wrong.
Even if you do handle this event, there is little can be learned other than the service host entered faulted state. If you are lucky and you are in a debugger, you will see the exception that MSMQ threw, otherwise there is no way to retrieve the exception, especially if the service host runs in a service application.
One common MSMQ exception is that "An error occurred while receiving a message from the queue: The transaction specified cannot be imported. (-1072824242, 0xc00e004e). Ensure that MSMQ is installed and running. Make sure the queue is available to receive from." The error code is MQ_ERROR_TRANSACTION_IMPORT (0xC00E004E), which typically means that the transaction coordinator is not available. It turns out that you would have to allow MSDTC on the service host machine to access the network if the queue is not local.
Turning on network access for MSDTC requires the use of some tools. They are hidden at some not-so-obvious places: you would have to run dcomcnfg, open "Component Services". In some versions of Windows "Component Services" is on the "Administrative Tools" menu, but in some other versions, it is not.
Once you have found "Component Services", you need to go to the properties dialog box of "My Computer". On the "MSDTC" tab, check "Use local coordinator".
We are not done. Under "My Computer" in "Component Services", go to "Distributed Transaction Coordinator", "Local DTC", and go to its properties dialog box. Go to the security tab, and check "Network DTC Access".
All this is too complicated to maintain for a simple WCF service, not to mention the security implications. If you really love MSMQ so much that you have to have it, then this would get it to work. But WCF can work with simpler protocols. These simpler protocols are more reliable and more secure. After all, what MSMQ does is simple, we can live without it.
Wednesday, March 31, 2010
ReorderList in AJAX .NET Control Toolkit Requires ClientIDMode="AutoID"
When using "ReorderList" from AJAX .NET Control Toolkit, I found that it has a "hidden requirement": its "clientIDMode" attribute must be set to AutoID.
If you look at the AJAX .NET Control Toolkit sample website, its ReorderList sample does not have this attribute set. But the ReorderList sample works fine. How is that possible? It is because this sample site has "clientIDMode="AutoID" set in its web.config file:
<system.web>
...
<pages ... clientidmode="AutoID">
...
</system.web>
In other words, all controls in this sample website have this attribute set automatically!
What happens if you do not have this attribute set on a ReorderList control? Well, you will not be able to drap and drop items to reorder them. If you look at the HTML code that is generated, the "_behavior" attributes that are supposed to go to each "li" element in the item list all get piled onto a single "div" element on the outside, along with the "DraggableListItem" attribute. So when you try to drag an item in the list, you will either get no response, or a stop-sign icon.
If you look at the AJAX .NET Control Toolkit sample website, its ReorderList sample does not have this attribute set. But the ReorderList sample works fine. How is that possible? It is because this sample site has "clientIDMode="AutoID" set in its web.config file:
<system.web>
...
<pages ... clientidmode="AutoID">
...
</system.web>
In other words, all controls in this sample website have this attribute set automatically!
What happens if you do not have this attribute set on a ReorderList control? Well, you will not be able to drap and drop items to reorder them. If you look at the HTML code that is generated, the "_behavior" attributes that are supposed to go to each "li" element in the item list all get piled onto a single "div" element on the outside, along with the "DraggableListItem" attribute. So when you try to drag an item in the list, you will either get no response, or a stop-sign icon.
Friday, March 12, 2010
Running Remote Desktop Connection in XP Mode of Windows 7
Many VPN clients would lock up network connection so that all traffic goes to the VPN gateway. You cannot browse the internet or make other internet connections from your computer without going through the VPN gateway.
To get around this restriction, we can use Windows 7's XP mode. We can run the VPN client and a remote desktop connection on Windows 7's desktop from the XP mode virtual machine. The XP mode virtual machine will then hold the exclusive connection to the VPN gateway.
However, setting up such an arrangement is far from easy. Normally, if you go into the XP mode virtual machine, and add a shortcut to a program in the folder
\Document and Settings\All Users\Start Menu\Programs,
the shortcut will show up in the Windows 7 host's start menu under "Windows Virtual PC", "Windows XP Mode Applications".
This does not work for Windows XP's Remote Desktop Connection. If you add a shortcut to \Windows\system32\mstsc.exe in that folder, the shortcut does not show up in the Windows 7 host's start menu.
There are a couple of suggestions on the internet that can fix this: one is to create a batch file that calls \Windows\system32\mstsc.exe, and then add a shortcut to this batch file in the folder
\Document and Settings\All Users\Start Menu\Programs
The other involves editing the shortcut file on the Windows 7 host.
I would like to offer another alternative. If you save your connection to another machine in a .rdp file, you can create a shortcut to this file in
\Document and Settings\All Users\Start Menu\Programs,
and this shortcut does show up in the Windows 7 host's start menu.
However, Windows XP's Remote Desktop Connection does not work well on Windows 7 host's desktop. It shows two windows for one. One is a local input capture window, and one is the remote desktop. When you minimize the remote desktop, the local input capture window stays, and cannot be hidden easily.
The solution is to install a Windows 7 virtual machine. The Windows 7 virtual machine can integrate with the Windows 7 host the same way as a XP mode virtual machine. The path for the shortcut is a little different. It is \ProgramData\Microsoft\Windows\Start Menu\Programs, not \Document and Settings\... as it is under XP mode virtual machine.
The virtual Windows 7's Remote Desktop Connection works flawlessly on the Windows 7 host's desktop.
Please note that you must install VPN client in the virtual machine, and you may need to run the VPN client from the Windows 7 host's start menu before starting the Remote Desktop Connection from the same menu folder.
To get around this restriction, we can use Windows 7's XP mode. We can run the VPN client and a remote desktop connection on Windows 7's desktop from the XP mode virtual machine. The XP mode virtual machine will then hold the exclusive connection to the VPN gateway.
However, setting up such an arrangement is far from easy. Normally, if you go into the XP mode virtual machine, and add a shortcut to a program in the folder
\Document and Settings\All Users\Start Menu\Programs,
the shortcut will show up in the Windows 7 host's start menu under "Windows Virtual PC", "Windows XP Mode Applications".
This does not work for Windows XP's Remote Desktop Connection. If you add a shortcut to \Windows\system32\mstsc.exe in that folder, the shortcut does not show up in the Windows 7 host's start menu.
There are a couple of suggestions on the internet that can fix this: one is to create a batch file that calls \Windows\system32\mstsc.exe, and then add a shortcut to this batch file in the folder
\Document and Settings\All Users\Start Menu\Programs
The other involves editing the shortcut file on the Windows 7 host.
I would like to offer another alternative. If you save your connection to another machine in a .rdp file, you can create a shortcut to this file in
\Document and Settings\All Users\Start Menu\Programs,
and this shortcut does show up in the Windows 7 host's start menu.
However, Windows XP's Remote Desktop Connection does not work well on Windows 7 host's desktop. It shows two windows for one. One is a local input capture window, and one is the remote desktop. When you minimize the remote desktop, the local input capture window stays, and cannot be hidden easily.
The solution is to install a Windows 7 virtual machine. The Windows 7 virtual machine can integrate with the Windows 7 host the same way as a XP mode virtual machine. The path for the shortcut is a little different. It is \ProgramData\Microsoft\Windows\Start Menu\Programs, not \Document and Settings\... as it is under XP mode virtual machine.
The virtual Windows 7's Remote Desktop Connection works flawlessly on the Windows 7 host's desktop.
Please note that you must install VPN client in the virtual machine, and you may need to run the VPN client from the Windows 7 host's start menu before starting the Remote Desktop Connection from the same menu folder.
Monday, February 22, 2010
AJAX Control Toolkit and .NET 4.0
If you would like to build a .NET 4.0 web application with Visual Studio 2010, and you would like to build the AJAX Control Toolkit from its source with .NET 4.0 as well, you may run into a little problem. Even though you can build the AJAX Control Toolkit itself just fine, but when you build your web application, the compiler will give an error: "Inheritance security rules violated by type: 'AjaxControlToolkit.TabPanelDesigner'. Derived types must either match the security accessibility of the base type or be less accessible."
A quick solution to this problem is to add the following to the "AssemblyInfo.cs" file of the AJAX Control Toolkit project (not your own web application project):
[assembly: SecurityRules(SecurityRuleSet.Level1)]
Of course, at the beginning of this file, make sure that you have
using System.Security;
After you have made these changes, rebuild the AJAX Control Toolkit, and then your web application. Your web application should build fine.
A quick solution to this problem is to add the following to the "AssemblyInfo.cs" file of the AJAX Control Toolkit project (not your own web application project):
[assembly: SecurityRules(SecurityRuleSet.Level1)]
Of course, at the beginning of this file, make sure that you have
using System.Security;
After you have made these changes, rebuild the AJAX Control Toolkit, and then your web application. Your web application should build fine.
Update: A later build of AJAX Control Toolkit now works with Visual Studio 2010 without modification.
MySQL .NET Connector and .NET 4.0
Whe building a .NET 4.0 application with MySQL .NET Connector 6.2.2, you may get an 0x80131515 error from the SGEN utility, saying that the operation is not supported.
Apparently Visual Studio 2010 does not like the fact that the MySQL DLLs are pulled from the global assembly cache (GAC). If you add file references to these MySQL DLLs in your project, everything works.
To remove MySQL .NET Connector 6.2.2 from the GAC, you have to uninstall it. That is right: you have to uninstall it to use it!
After you uninstall MySQL .NET Connector 6.2.2 from the control panel, you can unzip the MySQL .NET Connector 6.2.2 zip file that you download from MySQL, and then place the files at a location that you can reference from your project.
Add references to these files in your project by browsing to them, you can then build your project with .NET 4.0 without errors.
Apparently Visual Studio 2010 does not like the fact that the MySQL DLLs are pulled from the global assembly cache (GAC). If you add file references to these MySQL DLLs in your project, everything works.
To remove MySQL .NET Connector 6.2.2 from the GAC, you have to uninstall it. That is right: you have to uninstall it to use it!
After you uninstall MySQL .NET Connector 6.2.2 from the control panel, you can unzip the MySQL .NET Connector 6.2.2 zip file that you download from MySQL, and then place the files at a location that you can reference from your project.
Add references to these files in your project by browsing to them, you can then build your project with .NET 4.0 without errors.
Subscribe to:
Posts (Atom)