|
If Google is broken try bing
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Where can I find an exaustive guide or a well done tutorial, with/or commented examples about DATAREPEATER Control, distibuted together with Visual Basic Power Pack?
Thanks.
|
|
|
|
|
Have you tried Googling for "DataRepeater tutorial"?
|
|
|
|
|
On MSDN, off course. You can find an Introduction to the DataRepeater Control here[^]. There's a walk-through here[^], and your new homepage can be found here[^].
You're welcome. However, I didn't provide the material; the credits should go to MSDN
Bastard Programmer from Hell
|
|
|
|
|
|
Hi,
I am trying to enumerate system devices using .Net and keep receiving a null on the following code. How do I fix the problem? I saw several examples on the web, all showing similar code constructs.
try
{
clsidSystemDeviceEnum = new Guid("62BE5D10-60EB-11d0-BD3B-00A0C911CE86");
Type comType = Type.GetTypeFromCLSID(clsidSystemDeviceEnum);
object oEnum;
oEnum = null;
oEnum = Activator.CreateInstance(comType);
pSysDevEnum = oEnum as ICreateDevEnum;
if (null != pSysDevEnum)
pSysDevEnum.CreateClassEnumerator(clsidDeviceClass, out ppEnumMoniker, dwFlags);
else
return;
}
catch (Exception ex)
{
MessageBox.Show(ex.Message, Application.ProductName, MessageBoxButtons.OK);
}
Thanks in advance,
Sarah
|
|
|
|
|
Which line throws the NullReferenceException?
|
|
|
|
|
Hi,
Thank you for the response. Here is a better description of the problem. To answer your specific question, oEnum, the Activator.CreateInstance call.
I am trying to enumerate system devices using .Net. The problem that I have is that Activator.CreateInstance returns null, even though I pass in a valid System Device Enumeration GUIID class. You can search the registry and find it.
The result of Type.GetTypeFromCLSID(clsidSystemDeviceEnum, true) copy and pasted from the debugger window holding the oEnum variable is:
{Name = "__ComObject" FullName = "System.__ComObject"}
A Google search yielded a couple of hits that showed that Activator.CreateInstance will sometimes return a null when the type is "__ComObject" but the hits never went deeper. Several articles talk about device enumeration and all gave the same code, namely to start by enumerating the System Device Enumeration object.
You can see the code below. Please ignore the clsidDeviceClass. That is not relevant in the code below. That is used below in the part of the code not visible (in the etc., etc., etc. part). That variable will hold the SCSI Storage object, which is one of the system devices. Just to be specific, this variable will have the value, clsidDeviceClass = new Guid("2ACCFE60-C130-11D2-B082-00A0C91EFB8B");.
First thing is first and that is to resolve why I receive a null from the call to Activator.CreateInstance and of course how I can resolve the problem so that I get a valid object back.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.InteropServices;
using System.Windows.Forms;
using System.Runtime.InteropServices.ComTypes;
using System.Collections;
public void CreateClassEnumerator([In] System.Guid clsidDeviceClass, [Out] out System.Runtime.InteropServices.ComTypes.IEnumMoniker ppEnumMoniker, [In] uint dwFlags)
{
Guid clsidSystemDeviceEnum;
ppEnumMoniker = null;
try
{
clsidSystemDeviceEnum = new Guid("62BE5D10-60EB-11d0-BD3B-00A0C911CE86");
Type comType = Type.GetTypeFromCLSID(clsidSystemDeviceEnum, true);
object oEnum;
oEnum = Activator.CreateInstance(comType);
}
catch (Exception ex)
{
MessageBox.Show(ex.Message, Application.ProductName, MessageBoxButtons.OK);
}
}
Thanks,
Sarah
|
|
|
|
|
I just created a console project with your code and it did not return a null. Did you ensure that the C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include\uuids.h files exists as mentioned in the comments? Could be a missing COM interface.
|
|
|
|
|
Hi,
Thanks for the super quick response.
The header file is for informational purposes only and is not needed for compilation. I merely lifted the definition of the System Device Enumeration GUIID from that file. I figure that whomever wants to look at the code in the future should know where I got that GUIID from. Also, C# does not support header files, so...
I am glad that the code works on your end and that Activator.CreateInstance does not return a null on your end. My thought is that either the version of Visual Studio, OS version, or some other difference.
I use Microsoft Windows 7 Professional, 64-bit and Visual Studio 2010.
It might be a Visual Studio 2010 thing. I know that Microsoft ditched DirectShow from Visual Studio 2010, not that I am using DirectShow or need to, so might not be related, but mention. The reason the thought crossed my head is only because Direct<whatever> touches hardware in some form or fashion and that System Device Enumeration also touches hardware, although I am creating a COM object instance at this point in the code, so Activator.CreateInstance should return something other than null.
Thanks in advance,
Sarah
|
|
|
|
|
Yes, of course, C# doesn't need the header file to compile. But a missing header file can signal a missing COM component in the system. I use Win XP with Visual Studio 2010. And since you mentioned that you could in fact find the GUID in the registry, I was wondering what else could be wrong. Let me try with a Win 7 system.
|
|
|
|
|
I did a search to find the GUIID. I never even heard of that file before a search turned it up. As far as missing stuff, to my knowledge I have everything. I even installed a couple of days ago the latest Microsoft Windows SDK (v7.1) on my system.
Thanks for helping out Shameel!
|
|
|
|
|
I just tested it out in Windows 7 (32-bit) and Visual Studio 2010 and I got an object (Not null). Do you by any chance use 64-bit Win 7?
|
|
|
|
|
Yes, I run Widows 7, 64-bit.
|
|
|
|
|
As an alternative, you can try using WMI to enumerate system devices. This[^] article can get you started.
|
|
|
|
|
Thanks! I will take a look at the code.
I was hoping that .Net would behave a bit better on 64-bit (Win7). I guess Microsoft still has some bugs in their COM libraries (or would that be a .Net issue?). If a COM issue, that too is a bit surprising, as both 64-bit and COM has been around for some time. Even Adobe supports Flash on for 64-bit Windows. One would think that Microsoft would support true / full 64-bit COM, but I guess not.
|
|
|
|
|
COM Interop with 64-bit has always been a problem. This[^] post contains information about enumerating Sound devices, I think that is what you are looking for.
|
|
|
|
|
I am new to this whole area (enumeration, .Net, etc.). Thanks for both pieces of information. I assumed that the COM interop 64-bit services worked, but the adage about assume comes to mind.
I will check out the other article too!
|
|
|
|
|
Hi
please help me
I need a sample code for using crystal report in asp .net MVC project
please send to me if you have
thanks a lot
|
|
|
|
|
Hi
please help me
I need a sample code for using crystal report in asp .net MVC project
please send to me if you have
thanks a looooooooooot
|
|
|
|
|
I think you should try google. If that's not available, try Bing. If that's not available, if I were you, I would SERIOUSLY consider looking for another vocation, like sweeping standing water off sidewalks.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- "Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
I recently had a discussion at work about the use of Not... Is or IsNot.
It seems there is no difference between the two, except that IsNot looks more like how you would say something.
For example:
If something IsNot somethingElse Then
End If
However, I prefer Not... Is because that way you always know if something should be true or Not by looking at the beginning of a line of code, like so:
If Not something Is somethingElse AndAlso
something2 Is somethingElse2 AndAlso
Not something3 Is somethingElse3 Then
End If
That code looks clean, because Not (or not Not) is always at the same spot in the line. If I would use IsNot that just as well might not be the case. So by using Not... Is you always know if a condition must be true or not without having to search for the IsNot in every line of code.
But Not... Is sounds a bit weird if you say it out loud.
Does it make any difference 'under the hood' or is it simply a personal preference?
All my colleagues prefer IsNot by the way :p
It's an OO world.
|
|
|
|
|
Personal preferrence. There is no difference between the two "under the hood".
It was put into VB.NET because people were having a hard time reading code that negatated a expression to come up with the real true expression. Basically, the old way it forced people to do this:
Normal layout:
If expression Then
result if True
Else
result if False
End If
'Not' layout:
If expression Then
result if False
Else
result if True
End If
|
|
|
|
|
Thanks for the answer. That is really all I wanted to know
It's an OO world.
|
|
|
|
|
According to the MSDN:
The IsNot operator cannot be used to compare expressions returned from the TypeOf operator. Instead, you must use the Not and Is operators.
So there must be some difference somewhere.
|
|
|
|