|
I have an outlook bar that can recieve drag drop operations. I'm trying to get it so that when u drag a shortcut from the desktop into the outlook bar, it will add an item and use the icon from the shortcut as the picture for the outlook bar menu item that it adds. Ive already got the drag drop stuff working, and it adds an item to the outlookbar, but i cant figure out how to get the icon from the shortcut. Any ideas??
By BigBlob202
My Site - I just started it so theres not much on it.
|
|
|
|
|
P/Invoke the SHCreateFileExtractIcon function and declare the IExtractIcon interface. You can find more information about these in the Platform SDK on MSDN Library online[^].
You can also P/Invoke SHGetFileInfo if you know you'll be receiving the path to a file with an associated icon. This won't work for executable files (i.e., to get the icon located at index 1 in the executable's .rsrc section). Search this thread's comments (click "Search comments" above) for SHGetFileInfo for previous discussions and sample code.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
are there any examples of this, because i am confused. Please Help!
By BigBlob202
Dinco Inc.
|
|
|
|
|
As I mentioned the first time, why don't you search the comments of the C# forum for information on the SHGetFileInfo API? I've posted this code before. See Re: How do I find a file associated icon?[^]. This will work for files with file associations (files without associations will get the default icon).
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
SetWindowPos(m_hWnd,(IntPtr)12,0,0,Screen.PrimaryScreen.Bounds.Width/2,Screen.PrimaryScreen.Bounds.Height/2,11);
it does not compile wrong but returns false
|
|
|
|
|
Besides the fact that you can do all this without P/Invoking calls (using Form.Location and Form.Size, which you should use for portability and ease), you didn't mention how you declared the P/Invoked method, which should look like:
[DllImport("user32.dll")]
private static extern bool SetWindowPos(
IntPtr hWnd,
IntPtr hWndInsertAfter,
[MarshalAs(UnmanagedType.SysInt)] int X,
[MarshalAs(UnmanagedType.SysInt)] int Y,
[MarshalAs(UnmanagedType.SysInt)] int cx,
[MarshalAs(UnmanagedType.SysInt)] int cy,
[MarshalAs(UnmanagedType.U4)] UINT uFlags);Pass the Form.Handle property value as the first parameter.
Honestly, though - just stick with the properties already available on the Form class (some of which are inherited from Control). You don't need this function at all and will most likely break portability if you ever require it anyway.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
He's moving and positioning windows that don't belong to his app...
RageInTheMachine9532
|
|
|
|
|
but he realy does not do it
it always return false and dont resize or reposotion the window
There is another question
SWP_NOZORDER??
HWND_TOP??
how can i put these in the function
|
|
|
|
|
Find out what they're defined as in the Platform SDK headers.
private const int SWP_NOZORDER = 4;
private const int HWND_TOP = 0;
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
thanx for ur time
but i dont want to move my app form but i am moving an outside app and try to resize it
There is another question
SWP_NOZORDER??
HWND_TOP??
how can i put these in the function
|
|
|
|
|
My boss asked me come up with good and bad reasons for porting VC++ code to C#.NET.
Any experts out there who converted their projects and would like to share their good/bad experiences?
I appreciate your response. My boss is not .NET guy.
Promise only what you can do. And then deliver more than what you promised.
This signature was created by "Code Project Quoter".
|
|
|
|
|
The worst reason for working code: "because".
This is a bad reason for porting, and even Microsoft says so. If you have working code and want to use it in existing applications, you can either compile VC++ code using the new /clr switch for a mixed-mode assembly, or wrap it.
If you plan on migrating your entire code-base to .NET in order to facilitate RAD and and add features to the application, then it might be a good idea.
To avoid bad experiences, make sure you have knowledge people in .NET development - not C#. If they don't understand that C# is one of many languages that target the CLR and just what that means, you're going to have a lot of bad experiences.
Don't jump on the bandwagon because everyone else is. Make sure you have some good reasons.
My boss was SURE he wanted to do this new application (based on an old design in his former start-up that we're redoing now in this new start-up) and he didn't even know what .NET was. Fortunately I'd been working with it since 1.0 beta 1 or 2 and we started about 2 months after 1.0 was released. Since then, we had problems - mostly with IT - because of the .NET Framework requirement and lack of privileges on local systems.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Heath Stewart wrote:
Don't jump on the bandwagon because everyone else is. Make sure you have some good reasons.
That's the problem. It's been already 2 years since .NET 1.0 released. Now atleast my boss is willing to jump to .NET bandwagon. (apart from another project which I handled for another group which involved WebForms) But I suggested two ideas.
1. Port entire application. It takes money and time.
2. Create new .NET application and use Interop to talk to legacy non .NET (mostly COM) applications. It takes less money and less time, but this approach involves marshalling stuff. Any good link which shows the pitfalls in this direction?
Heath Stewart wrote:
If you have working code and want to use it in existing applications, you can either compile VC++ code using the new /clr switch for a mixed-mode assembly, or wrap it.
I hate the __gc stuff. 
Correct me if I am wrong, Heath.
Promise only what you can do. And then deliver more than what you promised.
This signature was created by "Code Project Quoter".
|
|
|
|
|
Kant wrote:
I hate the __gc stuff.
You don't need it. Just throwing on the /clr switch makes a mixed-mode assembly that you can use in other assemblies, but it's not verifiable code and can't (be default) be run from the network (of any kind). It works - really. There was even a ".NET Show" show about this a while back, though I knew about before.
Kant wrote:
Any good link which shows the pitfalls in this direction?
I don't really know about any discussing the pitfalls. In fact, in many cases Microsoft recommends this approach. Check-out Microsoft's Migration[^] site for articles. I remember reading one a while back, but can't remember where it is and can't find it now (it was on MSDN - my second home practically).
For the ".NET Show", see http://msdn.microsoft.com/theshow[^]. Click on Archives. I believe it was "Managed Code". Who knows - might've been "MSDN TV".
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
I don't know what you are doing with your code and in what scenerios you are implementing it but but from a StronglyTyped language perspective it is much more secure and almost impossible to generate buffer overflows...
Its also easier for "Less Expirenced" programmers to deal with. So if your organization has churn then new people will be more able to pick up wher you left off (wait, that might be a reason NOT to port to C#) 
Less development time etc....
Matthew Hazlett
Windows 2000/2003 MCSE
Never got an MCSD, go figure...
|
|
|
|
|
Kant wrote:
Any experts out there who converted their projects and would like to share their good/bad experiences?
It's a total rewrite.
MFC != .NET
multiple inheritance vs. single inheritance and interfaces means you are probably going to change some architecture somewhere.
pointers? HAHAHAHAHA
delegates and events. Cool, but rather different.
All those nice nifty third party controls that make pretty UI's and plug right into MFC? Forget it. Major PITA to integrate with .NET
Performance (.NET really is slower)
At this point, I'm right writing new apps for a client in C#. That still meant writing interfaces in C++ to the Ethernet drivers we're using (www.pcausa.com), the iButton devices we communicate with (www.ibutton.com), and the serial port drivers that support multidrop and nine-bit protocol (www.wcscnet.com). Sure, I do some pretty custom stuff, but the application automation layer was a total rewrite as well--data access layer, component management, form management, etc.
My client asked me if I wanted to rewrite our primary application in C#. I said "sure. Got $40,000?" He's probably invested that much in the MFC/C++ solution, and it there's nothing about C#/.NET that would make it any less expensive to rewrite, retest, re-screw up.
Marc
Microsoft MVP, Visual C#
|
|
|
|
|
Marc Clifton wrote:
there's nothing about C#/.NET that would make it any less expensive to rewrite, retest, re-screw up.
That's 100% correct. 
Promise only what you can do. And then deliver more than what you promised.
This signature was created by "Code Project Quoter".
|
|
|
|
|
Yep, I agree with Heath. Don't move it when it alreay works. If something needs a complete rewrite then thats not so bad, but otherwise keep maintaining it as is.
The question your boss probably wants to ask is why would I want to use C# over C++ in new projects, and are their scenarios where one is better over the other.
"Je pense, donc je mange." - Rene Descartes 1689 - Just before his mother put his tea on the table.
Shameless Plug - Distributed Database Transactions in .NET using COM+
|
|
|
|
|
Hello,
I set the BackgroundImage of my form to a bmp. Now, when I resize the form, I would like the background image to scale in size accordingly, so that when the from gets smaller the image shrinks.
Right now, when I resize the form, the image just gets cut off.
Any suggestions?
Thanx,
-Flack
|
|
|
|
|
You could either override the OnPaint method and scale and draw your background image before calling base.OnPaint, or override the OnResize method and scale the image, setting it as the new BackgroundImage. In the latter case, you'll have to create a Graphics using CreateGraphics in your form and call somethig like Graphics.ScaleTransform (which you could use in the override for OnPaint as well).
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
I was trying to limit some permissions on what certain methods can and cannot access. I wanted to disallow certain methods from accessing files. I found the FileIOPermissionAttribute, this seemed exactly what I wanted. But alas, if I use this attribute I cannot call showdialog on a form object.
[FileIOPermission(SecurityAction.PermitOnly)]
private void button1_Click(object sender, System.EventArgs e)
{
Form2 fm = new Form2();
fm.ShowDialog();
}
The exception text:
An unhandled exception of type 'System.Security.SecurityException' occurred in mscorlib.dll
Additional information: Request for the permission of type System.Security.Permissions.UIPermission, mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed.
Can anyone explain why a UIPermission exception is thrown?
-Nathan
---------------------------
Hmmm... what's a signature?
|
|
|
|
|
Because you're granting permissions ONLY for the FileIOPermission, not the UIPermission which Form.ShowDialog requires.
If you're new to .NET code access security, "UB" has an excellent article here on CodeProject, Understanding .NET Code Access Security[^]. You should also see the reference, Code Access Security[^], in the .NET Framework SDK.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Is there and easy way to deny access to all files, but still allow UI to be presented to the user?
Basically I am helping to develop a plugin architecture and we need to disable file access and possibly even socket access. So I was looking for something along the lines of:
filePerm.DenyAllAccess();
sockPerm.DenyAllAccess();
myPlugin.DoSomethingClever();
sockPerm.RevertDeny();
filePerm.RevertDeny();
<br />
<br />
Thanks,<br />
Nathan <br />
<br />
---------------------------<br />
Hmmm... what's a signature?
|
|
|
|
|
Typically, it's not your code's responsibility. That's what permissions sets that code groups use are for.
I don't see why you're trying to do this like you are. If a plugin calls your method, your method was written by "you" (possibly an org.) so you ultimately control what goes on in there. If you don't use files or sockets, how is a plugin supposed to change that?
Now, if you wanted to make sure that your application had certain permissions but plugins were more restricted, you should consider using a code group based on the strong name of your assembl(y|ies). With real-world applications, you should always sign your assemblies for added benefit, like the ability to be installed into the GAC, to be used by other strong-name assemblies, etc. Use the AssemblyKeyNameAttribute or the AssemblyKeyFileAttribute with a file generated by "sn.exe -k KeyFile.snk", which generates a key pair. Use this for all of your assemblies (putting it in a container with "sn.exe -i MyContainerName KeyFile.snk" and using the AssemblyKeyNameAttribute is often easier with large projects).
If you call one of your plugin methods as you do above, you have a number of things to consider. First, do you even trust the plugin? Perhaps checking the public key token and making sure it's the same as yours or another trusted source would be a good idea. If you want anyone to be able to extend your application, then you're on the right track. Create an instance of the permission(s) and call Deny on the instance. This also means that if callers higher in the stack are trying to access a resource, they won't be able to but a SecurityException will be thrown by callees lower in the stack when a Demand for that permission occurs.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Heath Stewart wrote:
If you want anyone to be able to extend your application, then you're on the right track. Create an instance of the permission(s) and call Deny on the instance.
I would like others to develop plugins so that is why I wanted to deny things around the method calls into that plugin. I don't want plugins to be able to do anything evil and such to the user's computer or via the user's computer. The plugin should get all information from the program and that is it.
I have found this to work around the method declaration of the abstract plugin methods.
abstract class plugin
{
protected abstract void OnDoSomething();
[FileIOPermission(SecurityAccess.Deny,Unrestricted=true)]
public void DoSomething()
{
OnDoSomething();
}
}
This will stop file accessing. But I found that the plugin derived from this can just do an FileIOPermission.Assert to get around this. Maybe I am thinking too much and there is no truly safe way to do these plugins.
Maybe at some point I have to trust my users...
Thanks again,
Nathan
---------------------------
Hmmm... what's a signature?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
