//[DllImport("someDll.dll")]
//private static extern uint someMethod(string s);
[UnmanagedFunctionPointer(CallingConvention.Cdecl)]
private delegate uint someMethod(string s);
[DllImport("kernel32.dll", SetLastError=true)]
private static extern IntPtr LoadLibrary(string dllToLoad);
[DllImport("kernel32.dll")]
private static extern IntPtr GetProcAddress(IntPtr hModule, string procedureName);
[DllImport("kernel32.dll")]
private static extern bool FreeLibrary(IntPtr hModule);
private static IntPtr libSomeDll;
private static IntPtr addrSomeMethod;
libSomeDll = LoadLibrary(Path.Combine(path, "someDll.dll"));
if (libSomeDll == IntPtr.Zero)
{
throw new Win32Exception(Marshal.GetLastWin32Error(), "LoadLibrary failed for someDll.dll.");
}
addrSomeMethod = GetProcAddress(libSomeDll, "someMethod");
if (addrSomeMethod == IntPtr.Zero)
{
throw new ApplicationException("GetProcAddress failed for someMethod.");
}
someMethod methSomeMethod = (someMethod)Marshal.GetDelegateForFunctionPointer(addrSomeMethod, typeof(someMethod));
uint result = methSomeMethod("");
bool result2 = FreeLibrary(libSomeDll);
Monday, November 30, 2009
How to use an unmanaged DLL from another location
Monday, November 09, 2009
How to use the OR operator in grep instead of the Windows pipe symbol
Doesn't work:
egrep firstTerm|secondTerm file.txtWorks: (caret '^' escape symbol)
egrep: (standard input): Not enough space
'SW1' is not recognized as an internal or external command,
operable program or batch file.
egrep firstTerm^|secondTerm file.txt
Friday, November 06, 2009
Visual Studio Edit and Continue
EDIT: LOOKS LIKE THIS IS ANOTHER ONE THAT DIDN'T ACTUALLY FIX IT... :-(
PLEASE LET ME KNOW IF YOU HAVE THE SOLUTION
A certain Visual Studio project wouldn't let me edit the code while debugging. It made debugging a real pain. I would get messages like this:
"Changes are not allowed when the debugger has been attached to an already running process or the code being debugged was optimized at build or run time."
There are different reasons why this type of message might come up. But in my case, eventually I discovered that the projects target frameworks didn't match. One project targeted 3.5 and the other targeted 2.0. Once I set both to 3.5, I could debug normally again.
PLEASE LET ME KNOW IF YOU HAVE THE SOLUTION
A certain Visual Studio project wouldn't let me edit the code while debugging. It made debugging a real pain. I would get messages like this:
"Changes are not allowed when the debugger has been attached to an already running process or the code being debugged was optimized at build or run time."
There are different reasons why this type of message might come up. But in my case, eventually I discovered that the projects target frameworks didn't match. One project targeted 3.5 and the other targeted 2.0. Once I set both to 3.5, I could debug normally again.
Thursday, October 01, 2009
Friday, September 18, 2009
How to make the DataGridViewComboBoxCell actually behave like one
Even though the DataGridViewComboBoxColumn has a property for DisplayStyle which can be set to either DropDownButton or ComboBox (or Nothing), there's virtually no difference that I can see between the two settings. What I want is to be able to type text into the control like a normal ComboBox. I was disappointed to find out that this functionality is not built in. But after some struggle tracking it down (which is why I'm posting this), I did find some information about how you can actually make it work (kind of). These are the key events:
private void dataGridView1_EditingControlShowing(object sender,
DataGridViewEditingControlShowingEventArgs e)
{
ComboBox cbo = e.Control as ComboBox;
if (cbo != null) {
cbo.DropDownStyle = ComboBoxStyle.DropDown;
cbo.AutoCompleteMode = AutoCompleteMode.SuggestAppend;
cbo.AutoCompleteSource = AutoCompleteSource.ListItems;
cbo.TextChanged -= new EventHandler(cbo_TextChanged);
cbo.TextChanged += new EventHandler(cbo_TextChanged);
}
}
private void dataGridView1_CellValidating(object sender,
DataGridViewCellValidatingEventArgs e)
{
object eFV = e.FormattedValue;
DataGridViewComboBoxCell cbc = dataGridView1.CurrentCell as
DataGridViewComboBoxCell;
if (cbc != null && !cbc.Items.Contains(eFV))
{
cbc.Items.Insert(0, eFV);
}
if (dataGridView1.IsCurrentCellDirty)
{
dataGridView1.CommitEdit(DataGridViewDataErrorContexts.Commit);
}
cbc.Value = cbc.Items[0];
}
private void cbo_TextChanged(object sender, EventArgs e)
{
dataGridView1.NotifyCurrentCellDirty( true );
}
Labels:
.Net,
C#,
Programming,
VisualStudio,
WinForms,
Work
Thursday, January 22, 2009
First impressions of JavaScript, from an old timer coming from Java/C#
It's interesting. There are no classes (exactly) or Main() method. Just put that code anywhere. Just create random global variables of some mysterious type that is at the same time no type and every type. Tack on random properties and methods anywhere and everywhere at your whim. Classes are implemented as functions and functions within functions. Everything works differently, yet it still manages to emulate object oriented programming effectively to some degree. JavaScript, you're not replacing my C#, but I was doubtful and yet you've managed to impress and intrigue me. You have evolved, and I'm having fun with you. <-- my ode to an inanimate programming language
Sunday, September 23, 2007
Reporting Services authentication on a Windows XP workgroup
After setting up my RAID server, I had installed Reporting Services on it, but until today I had not been able to connect to it from other computers in the workgroup. I would get the login prompt, but it would not accept any valid users.
After a lot of wasted time googling down the wrong trails, I finally found this excellent article that does a great job of explaining and provided the solution: http://www.windowsnetworking.com/articles_tutorials/wxpsimsh.html
The problem is on Windows XP, "simple file sharing" is turned on by default AND when it is, no matter what logon / password you use, the server uses the Windows Guest account instead. So even though I entered BlahBlahTest as the username, I was getting access denied messages because even through BlahBlahTest has access, Guest does not.
The weird thing is that I had tried turning off simple file sharing earlier in the night, and not only did it not fix the Reporting Services problem, but it also broke the file share I already had set up under simple file sharing; so I had turned it back on immediately.
The next day, I read this article, tried turning off simple file sharing again, created a new share -- for testing... both the new share and the existing share were fine, AND Reporting Services authentication worked perfectly. Weird and frusrating, but I'm happy it's fixed!
I had tried setting up VPN and a few other things requiring authentication a year or more ago, and had all kinds of problems. Now I realize that it was probably the same issue, it was ignoring the account I had set up, and using the Guest account instead. I'm excited to try some of this stuff again. Blogging this to remember what the deal was and save hours of googling again :)
Another useful thing I learned is that with Windows XP and higher, you can go into User Accounts on the control panel, and on the sidebar there is an option to "Manage your network passwords". By adding entries here, you aren't forced to use the same user on both the server and client machines. If your client user is different, just store the appropriate name and password for the network share here so you aren't prompted each time. Cool!
Just make sure simple file sharing is turned off on the server so it's not actually using the Guest account. ;)
After a lot of wasted time googling down the wrong trails, I finally found this excellent article that does a great job of explaining and provided the solution: http://www.windowsnetworking.com/articles_tutorials/wxpsimsh.html
The problem is on Windows XP, "simple file sharing" is turned on by default AND when it is, no matter what logon / password you use, the server uses the Windows Guest account instead. So even though I entered BlahBlahTest as the username, I was getting access denied messages because even through BlahBlahTest has access, Guest does not.
The weird thing is that I had tried turning off simple file sharing earlier in the night, and not only did it not fix the Reporting Services problem, but it also broke the file share I already had set up under simple file sharing; so I had turned it back on immediately.
The next day, I read this article, tried turning off simple file sharing again, created a new share -- for testing... both the new share and the existing share were fine, AND Reporting Services authentication worked perfectly. Weird and frusrating, but I'm happy it's fixed!
I had tried setting up VPN and a few other things requiring authentication a year or more ago, and had all kinds of problems. Now I realize that it was probably the same issue, it was ignoring the account I had set up, and using the Guest account instead. I'm excited to try some of this stuff again. Blogging this to remember what the deal was and save hours of googling again :)
Another useful thing I learned is that with Windows XP and higher, you can go into User Accounts on the control panel, and on the sidebar there is an option to "Manage your network passwords". By adding entries here, you aren't forced to use the same user on both the server and client machines. If your client user is different, just store the appropriate name and password for the network share here so you aren't prompted each time. Cool!
Just make sure simple file sharing is turned off on the server so it's not actually using the Guest account. ;)
Subscribe to:
Posts (Atom)