Yeah, I know, it's a complete waste of an entry, I just wanted to try out the new blogger engine and thangs, y'all know.
Check out http://salamitsunami.com/archives/91 for some laughs, old though I know it is. Maybe I can generate some hits, but then again, people might start reading this drivel.
Onk.
Monday, January 29, 2007
Sunday, October 29, 2006
The Bluetooth Saviour
I discovered a very useful little help page somewhere long ago, then lost it again. It was to do with installing WIDCOMM drivers for the USB BT dongle (mine's an ePox dongle.) Anyway, I found essentially the same document written by someone over at:
http://www.geekzone.co.nz/forums.asp?ForumId=8&TopicId=2200
I thought I would repost it here, as long as they don't mind, and hopefully it will stay available for all perpetuity...
This is a small guide for those who installed the Service Pack 2 for Windows XP and are experiencing problems with the WIDCOMM Bluetooth software..If you install the WIDCOMM BTW 1.4.2.10 Bluetooth software on Windows XP SP2, you will get the following error as soon as you double click on the blue-red system tray icon:"Your Bluetooth Software license does not include use with this Bluetooth Device"After that you will be asked to point to a valid license.dat file. However if you select the license.dat that came with your manufacturer's driver (be it on CD-ROM or downloaded from the manufacturer's website) it still won't work.The reason for this problem:In the Service Pack 2, Microsoft included a generic Bluetooth driver, naturally being WHQL-certified -- it's directly from Microsoft. The WIDCOMM Bluetooth driver however is not WHQL-certified, so Windows XP continues using the generic driver. This interferes with the WIDCOMM Bluetooth software resulting in the above error.To force Windows XP to use the WIDCOMM driver, perform the following steps:Don't plug in the Bluetooth device yet.If you have any Bluetooth software apart from the included Windows drivers installed, deinstall them and reboot. I am not sure if this is necessary, but just in case.Install the WIDCOMM BTW 1.4.2.10 Bluetooth software. When it asks you to plug in the Bluetooth device and click OK, don't, and click cancel instead.When the WIDCOMM setup has finished, plug in your Bluetooth device and let Windows install the driver. (There should be two Bluetooth icons in the system tray; one blue-white: this is the Windows driver - and one blue-red: this is the WIDCOMM driver which is deactivated.)Now go to the Device Manager, right click on the "Generic Bluetooth Radio" and select "updatedriver". Don't let Windows XP connect to the internet, then select "Choose software from a list or specified location". In the next window, select "Don't search, but select the driver to install".In the next window, activate "Show compatible hardware" (if it isn't activated already) and select your manufacturer's driver instead of the "Generic Bluetooth Radio" driver.Click next until the new driver is installed. Now the WIDCOMM system tray icon should be blue-white as well, activated and ready to use.If you now double click on "My Bluetooth Places" (e.g. on the desktop), the WIDCOMM software installation will be continued and finished.This should solve any compatibility issues with the WIDCOMM BTW 1.4.2.10 Bluetooth software and Microsoft Windows XP SP2.If you still experience problems, please reply to this thread. If necessary, I will update this HowTo accordingly.
http://www.geekzone.co.nz/forums.asp?ForumId=8&TopicId=2200
I thought I would repost it here, as long as they don't mind, and hopefully it will stay available for all perpetuity...
This is a small guide for those who installed the Service Pack 2 for Windows XP and are experiencing problems with the WIDCOMM Bluetooth software..If you install the WIDCOMM BTW 1.4.2.10 Bluetooth software on Windows XP SP2, you will get the following error as soon as you double click on the blue-red system tray icon:"Your Bluetooth Software license does not include use with this Bluetooth Device"After that you will be asked to point to a valid license.dat file. However if you select the license.dat that came with your manufacturer's driver (be it on CD-ROM or downloaded from the manufacturer's website) it still won't work.The reason for this problem:In the Service Pack 2, Microsoft included a generic Bluetooth driver, naturally being WHQL-certified -- it's directly from Microsoft. The WIDCOMM Bluetooth driver however is not WHQL-certified, so Windows XP continues using the generic driver. This interferes with the WIDCOMM Bluetooth software resulting in the above error.To force Windows XP to use the WIDCOMM driver, perform the following steps:Don't plug in the Bluetooth device yet.If you have any Bluetooth software apart from the included Windows drivers installed, deinstall them and reboot. I am not sure if this is necessary, but just in case.Install the WIDCOMM BTW 1.4.2.10 Bluetooth software. When it asks you to plug in the Bluetooth device and click OK, don't, and click cancel instead.When the WIDCOMM setup has finished, plug in your Bluetooth device and let Windows install the driver. (There should be two Bluetooth icons in the system tray; one blue-white: this is the Windows driver - and one blue-red: this is the WIDCOMM driver which is deactivated.)Now go to the Device Manager, right click on the "Generic Bluetooth Radio" and select "updatedriver". Don't let Windows XP connect to the internet, then select "Choose software from a list or specified location". In the next window, select "Don't search, but select the driver to install".In the next window, activate "Show compatible hardware" (if it isn't activated already) and select your manufacturer's driver instead of the "Generic Bluetooth Radio" driver.Click next until the new driver is installed. Now the WIDCOMM system tray icon should be blue-white as well, activated and ready to use.If you now double click on "My Bluetooth Places" (e.g. on the desktop), the WIDCOMM software installation will be continued and finished.This should solve any compatibility issues with the WIDCOMM BTW 1.4.2.10 Bluetooth software and Microsoft Windows XP SP2.If you still experience problems, please reply to this thread. If necessary, I will update this HowTo accordingly.
Thursday, October 19, 2006
Net Tears and Code, Sniff
Ok, so I've been right gettin inta CodeSmith and NetTiers this past few months and it's all wicked.
Seriously useful shit.
I'll post back here more when I can figure out exactly how to post code without having to trick the parser in the blogger.
Seriously useful shit.
I'll post back here more when I can figure out exactly how to post code without having to trick the parser in the blogger.
Monday, July 03, 2006
DataList ItemIndex and GridView DataItemIndex
I've been messing with things in .NET2 and found the following...
Inside a DataList you can do this:
(why else would you do it, d'oh!)
But in GridView you have to do this:
I use:
Inside a DataList you can do this:
< % # Container.ItemIndex % >Which databinds the current item's index to whatever so it can affect the rendered output
(why else would you do it, d'oh!)
But in GridView you have to do this:
< % # Container.DataItemIndex % >For example, I have a datalist in which I want to have a thick border around only the first item (an image and some text) in order to make it obvious that that is the main image in the gallery
I use:
But in a grid view, where i want a label in the first column of only the first row, I use:< border =" '" itemindex ="="">
' >
< runat="server" id="Label1" text="Main" visible="'" dataitemindex ="=""> '
/ >
Monday, October 17, 2005
This time it's technical
Ok, long time no post. Here's one for .NET developers having issues with the old
"Microsoft.Practices.EnterpriseLibrary.Data.Instrumentation.DataConnectionFailedEvent"
and occassional
"System.Security.SecurityException: Requested registry access is not allowed."
We changed server in the end. I did find a solution on a blog page somewhere, but I can’t find it now – here’s what I wrote in an email to a colleague:
1. Go to: “C:\Documents and Settings\All Users\Start Menu\Programs\Microsoft patterns & practices\Enterprise Library\Quickstart Applications\Logging & Instrumentation Application Block” or (if you downloaded Enterprise Library circa June 2005): "C:\Documents and Settings\All Users\Start Menu\Programs\Microsoft patterns & practices\Enterprise Library - January 2006\QuickStart Applications\Logging Application Block"
2. Load: “CS Logging QuickStart”
3. In ‘Solution Explorer’ highlight ‘Common’ (this should be the top project)
4. Open the drop-down menu over the ‘Common’ project
5. Select ‘Properties’
6. In the left-hand menu select ‘Configuration Properties’
7. In the left-hand menu select ‘Build’
8. In the right-hand pane, change the value for ‘Conditional Compilation Constants’ to: DEBUG;TRACE
9. Click OK
10. Change the build mode to Release
11. Rebuild the entire solution
12. Copy the Common, Configuration and Logging DLL's from the "C:\Program Files\Microsoft Enterprise Library\QuickStarts\Logging\CS\LoggingQuickStart\bin\Release" (if you downloaded Enterprise Library circa June 2005): "C:\Program Files\Microsoft Enterprise Library June 2005\src\Logging\bin\Release" into your own project (as you did way before you started getting all these errores)
13. Rebuild your own project.
Rebuild and it should work; you’re basically changing the build options of the project so as not to use the logging mechanism (ie: leaving out the part which is throwing the error). This is safe (for me, at least) because I never look at the logged output in the system logging application anyway; if I want logged information I use my own log (or stop points).
I think the default MS .NET logging is a good idea, but in practice it falls down because not enough developers get so deep into manipulating the system’s properties and functions to make it worthwhile figuring out a solution than writing their own. The logging is exactly this, good in principle, but requires lots of permissions which are, stupidly, not assigned by default to the .NET system user (if you’ve had problems writing files to supposedly permitted directories you’ll understand what I mean).
Ok, so I've decided to start recording my discoveries and successes in C# land here because otherwise I'll never have anything interesting to write. And I'll simply lose all my own solutions if I don't.
"Microsoft.Practices.EnterpriseLibrary.Data.Instrumentation.DataConnectionFailedEvent"
and occassional
"System.Security.SecurityException: Requested registry access is not allowed."
We changed server in the end. I did find a solution on a blog page somewhere, but I can’t find it now – here’s what I wrote in an email to a colleague:
1. Go to: “C:\Documents and Settings\All Users\Start Menu\Programs\Microsoft patterns & practices\Enterprise Library\Quickstart Applications\Logging & Instrumentation Application Block” or (if you downloaded Enterprise Library circa June 2005): "C:\Documents and Settings\All Users\Start Menu\Programs\Microsoft patterns & practices\Enterprise Library - January 2006\QuickStart Applications\Logging Application Block"
2. Load: “CS Logging QuickStart”
3. In ‘Solution Explorer’ highlight ‘Common’ (this should be the top project)
4. Open the drop-down menu over the ‘Common’ project
5. Select ‘Properties’
6. In the left-hand menu select ‘Configuration Properties’
7. In the left-hand menu select ‘Build’
8. In the right-hand pane, change the value for ‘Conditional Compilation Constants’ to: DEBUG;TRACE
9. Click OK
10. Change the build mode to Release
11. Rebuild the entire solution
12. Copy the Common, Configuration and Logging DLL's from the "C:\Program Files\Microsoft Enterprise Library\QuickStarts\Logging\CS\LoggingQuickStart\bin\Release" (if you downloaded Enterprise Library circa June 2005): "C:\Program Files\Microsoft Enterprise Library June 2005\src\Logging\bin\Release" into your own project (as you did way before you started getting all these errores)
13. Rebuild your own project.
Rebuild and it should work; you’re basically changing the build options of the project so as not to use the logging mechanism (ie: leaving out the part which is throwing the error). This is safe (for me, at least) because I never look at the logged output in the system logging application anyway; if I want logged information I use my own log (or stop points).
I think the default MS .NET logging is a good idea, but in practice it falls down because not enough developers get so deep into manipulating the system’s properties and functions to make it worthwhile figuring out a solution than writing their own. The logging is exactly this, good in principle, but requires lots of permissions which are, stupidly, not assigned by default to the .NET system user (if you’ve had problems writing files to supposedly permitted directories you’ll understand what I mean).
Ok, so I've decided to start recording my discoveries and successes in C# land here because otherwise I'll never have anything interesting to write. And I'll simply lose all my own solutions if I don't.
Subscribe to:
Posts (Atom)