Weird... I have Win7 SP1 x64 ADO Interface Hack VB6 SP6 I just tried that statement in a new project, no errors. I normally run Compatibility for Vista and disable Desktop Composition. I switched it to Compatability to XP SP3 and re-enabled Desktop Composition. Same thing.

Yeah I think you're right, a tagged expression would be much more easily parsed. Even a {x####} and {u####} could be easily extracted with some simple regexps. Thanks!

Say you had a textbox with a property named "WhiteSpaceChars" of type string. Each char in the string is what should be a white space character. the default value for this string would be (in c# code) whiteSpaceChars = " \t\r\n"; Now I would like that string to show up in the property designer for users to be able to edit. Now obviously the default string TypeConverter in windows forms can't handle these particular characters. However if I had a TypeConverter that could handle the c# string literal syntax my problem would be solved. This goes both ways, if the user types in a value of \x00010 I would like the appropriate string returned to my class as if it were a string literal.

Does anyone know of a class that can convert a string in the c# string literal format to a regular .NET string and vice versa? I want to have a designable string property that allows special characters and I figure a TypeConverter that supports the c# string literal format is probably the easiest way to do it, unless there exists a better way? Thanks

Same principal applies. Pretend it's exactly like a table in the same database but put a [Database].[Schema] in front of it like "database2.dbo.table"

If you're really good with COM a quick search of MSDN for MSHTML will bring up all you need to get started. If you aren't all is not lost. You can achieve ~90% of anything you need to do with scripting. If you explain what you're goal is i might be able to come up with a plan for achieving it.

Yes this is a standard feature. When the DropDown window is displayed it sets MousCapture. The intention is to prevent an accidental command from executing from an inadvertand mouseclick intended to close the dropdown window.

All of the HTML input controls with the exception of SELECT are Windowless. You cannot use regular Win32 techniques to play with them. :( Rather you have to use MSHTML.

Sure you could do it. There are limitations, though. For one thing ADO objects are unsafe so the user will have to lower their Internet Security. Also you'll have to make sure that the user has an adequate MDAC installed. Also there are no objects like Server available to resolve your names. If you're using Access, you have to use physical file paths. (Either Map a drive or use UNC (\\) notation) as it needs Read/Write file permissions to work (and doesn't work over WebDav like other office programs will). Lastly the network connections ADO makes won't run over most firewalls. So if you're dealing with a local Intranet Scenario where you have tight control over the client the answer is yes. If not the answer is a practical no. (Its possible, but way too much work to be worth it).

Believe it or not there's a little bit of work involved... :eek: Using Windows XP Visual Styles With Controls on Windows Forms

Change all your longs to uint. You're passing 64bit values to a function that's expecting 32bit.

I was able to reproduce the behavior doing to following: I made a class: test with properties Name and Id. Set the ComboBox's DataSource to a test[] With Name as DisplayMember and Id as ValueMember Set Sorted=true Noting that I had to set sort before setting the DataSource property otherwise it will throw an exception. In thinking about it the behavior makes sense that it could happen this way. When you set the DataSource of a ComboBox it copies the list to its own internal list. Text returns the item in the internal list. SelectedValue uses a combiniation of CurrenctManager ,SelectedIndex and ValueMember to retrieve an Item from the datasource. SelectedItem is probably a pointer stored in the internal list that gets Sorted with Text. Anyways Sorting your DataSource (via Array.Sort, ArrayList.Sort, DataTable.DefaultView.Sort; whatever the type of DataSource you have) should fix the problem. Even if the Sorted property inadvertantly gets set on the combobox, there's no mismatch between your datasource and its internal list because its already sorted.:)

It will work if this is an ASP page. If you're trying this by running a .vbs file from your desktop it won't because you're using WSH. Again if you're running Server-Side Web pages (I'm assuming this since this is the ASP, ASP.NET forum) VBScript is about the easiest way to go. If this is a desktop app you'll get better performance running full VB. Of course if possible I'd recommend using .NET.

If this code is in your Init event make sure your checking for Page.IsPostBack otherwise your controls get re-created and initialized on every PostBack.

Server.MapPath(_RelativePath_) will give the absolute physical path of a relative path (relative to the current ASP page)

I don't suppose you're setting the Sort property on the combobox? If not maybe an explicit set to false would do the trick

I think Crystal Reports which comes with VS Enterprise Architect has PDF export functionality

Use the [Registry](http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfmicrosoftwin32registryclasstopic.asp?frame=true target=) class to modify HKEY_CURRENT_USER\Control Panel\Desktop\WallPaper OR Use the Windows API function SystemParametersInfo(). You'll have to DllImport it from user32 and lookup the constants in winuser.h

fundamental mistake: Placing an open connection object is about the quickest way to bring a web server to its knees. I suggest placing only the connection string in the application object (assuming the connection string does not change throughout the lifetime of the application) this will give you something like thus: Global.asa

Sub application_onstart
application("constring")="PROVIDER=SQLOLEDB;SERVER=localhost;DATABASE=pubs;uid=sa;pwd=;"
end sub

anASPPage.asp

...
objRS.Open QUERYSTRING,Application("constring")

Or to go one step further in conserving resources:

objCon.Open Application("constring")
objRS.Open QUERYSTRING,objCon
...
objRS.Close
objCon.Close

With the SessionID being a 32bit number it's more likely to issue a duplicate than say a 128bit, but still ultra-unlikely. The only issues I've ever heard of regarding ASP Sessions are the session cookie hashes being sniffed over the network.