|
Hi...
I am writing a windows explorer toolbar that sets up a standard st of columns (like author, comments, etc..) so the user dosn't have to do it..(later will add more functions for handeling MS office documents etc..)
Now i have a working toolbar and have made my way through explorer to the lSysListView32 and using a LVCOLUMN managed to send the message that inserts the column..
But (allways a but) dose any one know how to tell explorer to populate the column with the info? I am only using standard columns (like author, comments, etc..)
Code So far...
<br />
private void button1_Click(object sender, System.EventArgs e)<br />
{<br />
MessageBox.Show("Button Clicked!");<br />
SendMessage(Explorer.HWND, LVM_COMMAND, viewREPORT, 0);<br />
IntPtr lSHELLDLLDefView = FindWindowEx(Explorer.HWND, 0, "SHELLDLL_DefView", null);<br />
if (lSHELLDLLDefView == null)<br />
{<br />
return;<br />
}<br />
IntPtr lDUIViewWndClassName = FindWindowEx(lSHELLDLLDefView, IntPtr.Zero, "DUIViewWndClassName", IntPtr.Zero);<br />
if (lDUIViewWndClassName == null)<br />
{<br />
return;<br />
}<br />
IntPtr lDirectUIHWND = FindWindowEx(lDUIViewWndClassName, IntPtr.Zero, "DirectUIHWND", IntPtr.Zero);<br />
if (lDirectUIHWND == null)<br />
{<br />
return;<br />
}<br />
IntPtr lCtrlNotifySink = FindWindowEx(lDirectUIHWND, IntPtr.Zero, "CtrlNotifySink", IntPtr.Zero);<br />
if (lCtrlNotifySink == null)<br />
{<br />
return;<br />
}<br />
IntPtr lSysListView32 = FindWindowEx(lCtrlNotifySink, IntPtr.Zero, "SysListView32", IntPtr.Zero);<br />
if (lSysListView32 == null)<br />
{<br />
return;<br />
}<br />
<br />
LVCOLUMN lvc = new LVCOLUMN();<br />
lvc.mask = 0x0001|0x0008|0x0002|0x0004;
lvc.fmt = 0x0001;<br />
lvc.cx = 100;<br />
lvc.text = "Author";<br />
<br />
int counter = 0;<br />
SendMessage(lSysListView32, 0x1000 + 97, counter, ref lvc);<br />
<br />
}
Not sure if this is the right forum but it is writen in C# but is probably more to do with good (well) old windows...
Many Thanks Calvin
|
|
|
|
|
This wont work. What you've done is told the listview to add the column, but Explorer doesn't know you did it and, hence, it wont fill the column.
You need to tell Explorer to add this column to the display so it also knows to fill in the data. The problem is there isn't a documented way to do this that I know of.
|
|
|
|
|
Ok.. I get it... I am looked into IShellBrowser.GetViewStateStream, but carn't seem to get it working in c#, so now i am looking into the registery settings... HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam\BagMRU so i can make a button that aplies a template..
Filename,Author,subject,catagory, and comments.. are the column heading i want to set...
calvin streeting
|
|
|
|
|
Hello everyone,
Could anyone let me know why compiler can not make runtime error report in the following code, other than throw cast exception during runtime?
static void Main()
{
int i = 100;
object b = i;
long l = (long)b;
return;
}
thanks in advance,
George
|
|
|
|
|
What you are doing is unboxing b by casting it as a long - this happens at runtime.
Also i does not equal 100 - i is an object pointing to 100 which is why an error is thrown.
In short i is an object and not an int so casting it to int throws an error.
Continuous effort - not strength or intelligence - is the key to unlocking our potential.(Winston Churchill)
|
|
|
|
|
That is not the answer to his question.
that is just the reason why it gives a runtime exception.
the question was why there is no compiletime check.
And the short answer to that is that MS was too lazy to make the compiler check for those kinds of things.
All the information is right there in the code:
int i=1;
object o=i;
long l=(long)o;
So it should be perfectly possible to make compiler support to find the error.
Aand "lazy" might be the wrong word, the might just think that the developer should find such problems, that the complexity to implement it is greater than the benefit of the feature..
|
|
|
|
|
Thanks Roger,
What are the Microsoft compiler's rule to check type conversion issues -- even if compiler is "lazy", it should also has rule to check right/wrong?
regards,
George
|
|
|
|
|
Roger Alsing wrote: And the short answer to that is that MS was too lazy to make the compiler check for those kinds of things.
In the contrived example shown, yes, I can see that the compiler could potentially make the determination. But in the real world how many times do you have such a trivial example. Almost never, I'd recon.
In the real world the compiler couldn't tell what the object reference is likely to be at compile time. And if the object reference came in via an argument on a public method then it would never be able to make that determination because it could be called by code outside the assembly which the compiler would have zero knowledge of.
At the end of the day there is limited resources into making the product and I think it is a little disengenous to say that Microsoft are "too lazy" for producing a complier check that has increadibly limited scope in a real world environment.
|
|
|
|
|
Thanks Colin!
It is ok for me the compiler does not check everything even if our human can see. 
My question is, I want to know what C# compiler check for type conversion (even if it is simple and can not find all the issues until runtime, I want to know the rules). Any ideas?
regards,
George
|
|
|
|
|
You know, I already stated that in my original reply 
>>and "lazy" might be the wrong word, they might just think that the developer should find such
>>problems, that the complexity to implement it is greater than the benefit of the feature..
|
|
|
|
|
Thanks Roger,
I mean lazy is ok, but there should be some rules coded in C# compiler to do the check, right? Any document?
regards,
George
|
|
|
|
|
it _is_ possible to find that problem at compiletime. (in the context that the OP gave)
But that feature is not present in the current C# compiler(s)
And the reason it is not present is most likely that the benefit you would get from such feature is so small that it makes it pointless.
which I did state at the end of my post.
So what in that post makes it worth 1 votes?
modified on Sunday, May 4, 2008 2:02 PM
|
|
|
|
|
|
Thanks GuyThiebaut,
We can only unboxing to the original type? Could we unbox to a type's base type?
regards,
George
|
|
|
|
|
George_George wrote: Could we unbox to a type's base type?
Yes.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
A little messy in the context. I want to confirm with you that you mean we can only unbox to the exact same original type (no other types are allowed)?
regards,
George
|
|
|
|
|
You can unbox to the actual type, or any (non-abstract) base type.
This works:
public class TypeX {}
public class TypeY : TypeX {}
TypeY y = new TypeY();
object o = y;
TypeX x = (TypeX)o;
Edit:
A more useful example of when you unbox to a base type, is when you box from a base type:
public class Animal {}
public class Dog : Animal {}
public class Horse : Animal {}
Animal hero = new Horse();
object o = hero;
Animal horsie = (Animal)o;
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Sorry, Guffa!
I am confused. In my understanding, boxing/unboxing only happens with value types, classes are not value types, but you are using classes in your sample? Any comments?
regards,
George
|
|
|
|
|
You are right, what my code example shows is not boxing. It demonstrates that you can cast a reference stored in an object reference variable to the actual type or one of it's base types.
For boxing, you can only unbox to the actual type that was boxed. A value type can not inherit another value type, so there is never any base type that you could unbox to instead.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
|
George_George wrote: "A value type can not inherit another value type" -- so Object is just the base for all reference type, not value type?
No, all types are derived from Object.
George_George wrote: I do not agree with it, since all value types inherit from System.ValueType, and System.ValueType inherits from Object. Any comments?
A value type can not inherit another value type. It inherits the abstact class ValueType, but never any actual value type.
The documentation says:
"All value types are derived implicitly from the System.ValueType."
But also:
"Structs can implement an interface but they cannot inherit from another struct."
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
One further question, I think for primitive types, there are pairs of relationship, example int and Int32 are the same thing, only different in names. Is my understanding correct (I can not find answers from any books or search)?
regards,
George
|
|
|
|
|
Yes, in almost every aspect int and System.Int32 is exactly the same thing.
There are some special cases where there is a difference. You can for example not use System.Int32 to specify a type for an enum:
enum MyEnum : int { asdf }<br />
<br />
enum MyEnum : System.Int32 { asdf }
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
1.
Good to learn from you. I have never used type information after Enum to restrict the type of Enum -- and just use the default one -- I think it is int type?
2.
So, a further question, what types could be used with Enum definition to define the type of the Enum?
regards,
George
|
|
|
|
|
George_George wrote: Good to learn from you. I have never used type information after Enum to restrict the type of Enum -- and just use the default one -- I think it is int type?
Yes, it's int.
George_George wrote: what types could be used with Enum definition to define the type of the Enum?
It can be any integral type except char (i.e. sbyte, byte, short, ushort, int, uint, long or ulong).
enum (C# reference)[^]
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
