|
It sounded like a great idea, but I tried it and the event does not get called when the menu goes away. I think you have to actually dispose of it to generate that event.
Any other ideas?
Darryl Borden
Principal IT Analyst
darryl.borden@elpaso.com
|
|
|
|
|
Hi, I have being trying everything for the last hour and can't find anything in the .NET classes to make a tooltip for the treeview nodes. You can only register the tooltip for the control (the tree) whereas I need to add it for the nodes so when the mouse stops on them the tooltip will show up. I tried many tricks like using the mousepositions and getting the node name by the x and y position and then making a tooltip when the mousemove is fires and things like that. But they all reach an end point where first the code is inefficient and second one thing at least goes wrong (like the tooltip appears for ever and otherthigs like that) Does anyone know how to do this in the propper way?
Thanks
K.D.
|
|
|
|
|
The way you've described it is the way I've done it. Basically, you create a ToolTip on your form. Then in the control's OnMouseHover() event, you use the mouse position to figure out what text should be in the ToolTip, set that text on the ToolTip object, and then enable the ToolTip and show it. After that, you can either have the ToolTip timeout automatically, or keep it alive until the mouse moves out of that TreeNode's visible region.
--
Russell Morris
"Have you gone mad Frink? Put down that science pole!"
|
|
|
|
|
In the following example, I use a Tootip control and I create a new class derived from the TreeNode class. This class contains a Tooltip property. And I display the tooltip when receiving the MouseMove event, using the GetNodeAt method to know what is the node pointed by the mouse.
using System;
using System.Drawing;
using System.Windows.Forms;
class TreeViewWithTooltip: Form
{
private ToolTip m_tooltipCtrl = null;
public static void Main()
{
Application.Run(new TreeViewWithTooltip());
}
public TreeViewWithTooltip()
{
Text = "Tree View with tooltip";
m_tooltipCtrl = new ToolTip();
TreeView tree = new TreeView();
tree.Parent = this;
tree.Dock = DockStyle.Fill;
tree.ShowLines = true;
tree.MouseMove += new System.Windows.Forms.MouseEventHandler(tree_MouseMove);
MyTreeNode myTreeNode1 = new MyTreeNode("This is node 1");
myTreeNode1.Text = "node1";
tree.Nodes.Add(myTreeNode1);
MyTreeNode myTreeNode11 = new MyTreeNode("This is node 11");
myTreeNode11.Text = "node11";
myTreeNode1.Nodes.Add(myTreeNode11);
tree.ExpandAll();
}
private void tree_MouseMove(object sender, System.Windows.Forms.MouseEventArgs e)
{
TreeView tree = (TreeView)sender;
MyTreeNode myTreeNode = (MyTreeNode)tree.GetNodeAt(e.X, e.Y);
m_tooltipCtrl.SetToolTip(tree, myTreeNode != null ? myTreeNode.Tooltip : null);
}
}
class MyTreeNode : TreeNode
{
private string m_tooltip;
public MyTreeNode(string tooltip)
{
m_tooltip = tooltip;
}
public string Tooltip
{
get { return m_tooltip; }
set { m_tooltip = value; }
}
}
|
|
|
|
|
Thanks for the code, but the problem is that I want it to act like regular tooltip which fades away after a while(without going out of the whole tree control) when staying staionary for some time.
Add the following line to your code in the event handler and you will see that the tooltip comes right back on, as soon it fades. I think it somehow calls the mousemove event when the tooltip shows up!
m_tooltipCtrl.AutoPopDelay = 1000;
any ideas?
K.D.
|
|
|
|
|
Hi,
I need to delete files that are in use.
I can´t restart my computer or neither exit programs that are using them. Any suggestions? Need to work on NT/2000 server.
/Ola Carlsson
|
|
|
|
|
You can't delete a file that's in use - that could break someone else's running program. You can mark them for deletion on reboot or you can kill the other programs that are using it.
Paul
Why don't you take a good look at yourself and describe what you see - Led Zeppelin, Misty Mountain Hop
|
|
|
|
|
How do you mark a file for deletion on reboot? I didn't know you could do that! Do tell!
|
|
|
|
|
Registry Key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\
Name=PendingFileRenameOperations
Type=REG_SZ_MULTI
Entry=filename.txt\0\0
Or using the Win32 API, you can use MoveFileEx with a null destination file and MOVE_DELAY_UNTIL_REBOOT.
[edit]Probably worth noting, in case someone comes searching later that the first approach doesn't work on Win 9x or ME, only on NT/2K/XP. To use in 9X, you have to store some details in WININIT.INI; to use in all versions of Windows, MoveFileEx is probably your best bet.[/edit]
Paul
Why don't you take a good look at yourself and describe what you see - Led Zeppelin, Misty Mountain Hop
|
|
|
|
|
Hi,
I've developed a thin client for a project I'm working on, that gets presented with a load of assemblies to load when it connects to the hub (a web server on the network which exposes a few webservices). It then proceeds to load these assemblies using the System.Reflection.Assembly.LoadFrom(<url>) static method.
When it downloads the modules from the server I'd like to be able to display a status message to the user and update a progress bar as to the download size and progress.
This is purely from a support issue side of things, because the application either loads it from the GAC or from the server depending on the version. If a client stop working suddenly it would be nice for the user to be able to tell me when it updated the assembly.
Does anyone have any ideas?
--
Richard
|
|
|
|
|
>>
Richard Smith wrote:
It then proceeds to load these assemblies using the System.Reflection.Assembly.LoadFrom() static method.
<<
I'm not sure about the actual question you ask - but this isn't the preferred method for handling that scenario. I beleive the preferred method for doing this is to use a .config file for your thin client app that uses the <assemblybinding> tag to redirect the assembly loader to a URL when it looks for certain assemblies (as long as those assemblies have strong names). This will allow you to link directly to your assemblies that are to be deployed on the server, instead of having to use reflection.
So if your thin client linked to MyServerSideAssembly.dll, version=1.0.0.0, culture = neutral, public key token = 012345 , you would have a 'yourthinclient.config' file that contained something along the lines of:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="MyServerSideAssembly"
publicKeyToken="012345"
culture="neutral" />
<codeBase version="1.0.0.0"
href="http://your.server.com/MyServerSideAssembly.dll"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
You would then deploy MyServerSideAssembly.dll to a the 'your.server.com' web server.
The assembly loader will take care of downloading the assembly, caching it, and proceeding from there when the thin client tries to reference a type defined in 'MyServerSideAssembly.dll'.
Take a look at the '.Configuration file schema' in MSDN help to get a good idea of all the nifty things you can do with .config files.
--
Russell Morris
"Have you gone mad Frink? Put down that science pole!"
|
|
|
|
|
Hmmm interesting... However it doesn't apply since the runtime will only look for one version:
After determining which assembly version to use, the runtime applies the codebase setting from the file that determines the version.
MSDN: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/gngrfcodebase.asp
I need to be able to update the assembly and not have to worry about updating the client config files. When there's lots of them it gets a pain.
Plus what's downloaded is directly linked to what permissions they have been assigned and what group their in.
Plus I want to play 
--
Richard
|
|
|
|
|
|
I've been developing with MFC for a fair old while now, and I'm looking into c# - but I have a couple of absolute beginners questions before a think about my "beginners project":
1. Does c# / .net have anything like the doc/view architecture? (And if so, what's it called?)
2. Can anyone recommend any good books on moving from MFC to c#? I have a couple of c# text's, but I was hoping for something that might be able to help MFC coders with the migration to c#. Or would people say that this insn't required?
Dylan Kenneally
London, UK
|
|
|
|
|
It is my experience that C# is very primitive compared to MFC. However people are working to rectify the C# GUI shortcomings.
http://www.sellsbrothers.com/tools/genghis/[^]
Michael
"I've died for a living in the movies and tv.
But the hardest thing I'll ever do is watch my leading ladies,
Kiss some other guy while I'm bandaging my knee."
-- The Unknown Stuntman
|
|
|
|
|
Michael P Butler wrote:
It is my experience that C# is very primitive compared to MFC.
Would that be a recommendation for VC++.NET?
I'm still debating which one to learn - well, actually I want to learn both, but I want to start with whichever one is more in demand to try and make my skills as desirable to employers as possible, as soon as possible.
Dylan Kenneally
London, UK
|
|
|
|
|
I doubt there will be a "more in demand" between MC++ (get used to calling it that) and C#, to be honest. Both suit different needs and both needs will have a market.
MC++ will certainly be easier for you to learn, but then C# is hardly rocket-science either.
Incidentally, if you're looking for Document/View architechtures in C#, you're looking in the wrong place 
Paul
Life is just a sexually transmitted desease - Matthew Wright (ex-journalist, TV presenter) 10-Oct-02
I finally have a sig! - Paul Riley (part-time deity) 10-Oct-02
|
|
|
|
|
Dylan Kenneally wrote:
Would that be a recommendation for VC++.NET?
It depends on what you want to write. Personally I find the disadvantages in the C# GUI outweigh the .NET framework advantages.
I'm sticking with MFC for writing desktop applications and not using any of the .NET framework.
I'm still learning C# but it won't be usedto write any real world code that requires a lot of UI. I'll wait for the next release for that.
Michael
"I've died for a living in the movies and tv.
But the hardest thing I'll ever do is watch my leading ladies,
Kiss some other guy while I'm bandaging my knee."
-- The Unknown Stuntman
|
|
|
|
|
.NET for me is only for self-training at home. C++ is brute force.
Think redistribution : to launch your .NET app, users have to download between 20MB and 180MB of MS run-times. In addition, you don't control the redistribution, unlike the MFC dlls, which means users may update the .NET run-time without telling you, and may not be able to run your app any longer then (more than 100 behaviour updates between .NET 1.0 and .NET 1.1, almost none are backward compatible).
She's so dirty, she threw a boomerang and it wouldn't even come back.
|
|
|
|
|
__Stephane Rodriguez__ wrote:
In addition, you don't control the redistribution, unlike the MFC dlls
Very interesting point. So we have to trust MS about compatibility ?
Some of those that work forces
Are the same that burn crosses !
Killing In The Name/Rage Against The Machine
|
|
|
|
|
Until .NET has more playground, apps developed by you will generally speaking not work on an end user machine, because of a wrong .NET run-time (huge redistribuables by the way, think about those connecting the net with dialup).
KaЯl wrote:
So we have to trust MS about compatibility ?
It's obvious that the business model of MS is to promote a .NET certification. In other words, MS is more and more expecting us to go through their sort of exam before our app is said to be "compliant", or ".NET proofed" or whatever.
This is not really new stuff. We know for years there was the windows logo program, even if in practice almost no MS-partner company in the world can achieve it.
We are just at the premisses of that, but you've got the idea. You can figure it out by downloading FxCop (gotdotnet.com).
It's about figuring out why MS started all that hype around security last year. They wanted to tell everyone (make everyone blindly think), that new tools are more prone to enforce reliable security. They have said if users want more security, they'll have to go definitely the .NET way, which means upgrading their OSes. In turn, developers are going to be asked to develop only .NET apps (because MS claims this is better for security) which is not only a loss of freedom, but although a way to constraint developers to BUY all possible .NET related stuff, download, install, test, etc.
Which means this is the end of low-budget software development.
"On ne prête qu'aux riches...".
How low can you go ?
(MS retrofuck)
|
|
|
|
|
Thx for this detailled answer 
Influence of the Evil, Influence of the Good, which of both will go further?
Wobbly destinies, dubious dreams, which of both is good for nothing?
L'emprise du Mal, l'emprise du Bien, lequel des deux ira l'plus loin?
Destins bancals, rêves incertains, lequel des deux est bon à rien?
Come On Boys/Ludwig Von 88
|
|
|
|
|
__Stephane Rodriguez__ wrote:
Think redistribution
This statement is only correct if you are writing an app to be distributed to end-users online. If you are shipping by CD, or if you are mainly supplying software to corporations, or are an IT division developing in-house software, this is not a concern. And I think those areas are the ones that MS has been targetting for the first wave up .NET users.
It'll be years, I think, before the .NET framework is widely distrubuted enough among the average computer user for it to make sense to develop end-user/consumer software with .NET. It's big impact in the next few years (if it has one) will be on the server side and in corporate backends.
[Edit]
--> In regards to framework versions and such (sorry, I hit the submit button instead of the reply button  )
[/Edit]
DotNet 1.1 can be installed on the same computer as DotNet 1.0. An app written for 1.0 will run with the 1.0 framework, and an app written for 1.1 will run under the 1.1 framework.
If only the 1.1 framework is installed, the 1.0 app will try to run under the 1.1 framework. And most likely it will fail miserably, because of the imcompatibilities you point out. However, I don't see how this is any different than other upgrade scenarios, unless upgrades are never anything more than bugfixes that don't change interfaces.
If only the 1.0 framework is installed, the 1.0 app will run fine, and the 1.1 app will refuse to run.
The big problem I see with going from 1.0 to 1.1 is not getting built applications to run, it's rewriting your 1.0 apps when it turns out they are using behavior that has been altered in 1.1. This scenario worries me, of course. Our shop isn't looking at using 1.1 in the next year, as far as I know.
--
Russell Morris
"Have you gone mad Frink? Put down that science pole!"
|
|
|
|
|
Russell Morris wrote:
If only the 1.0 framework is installed, the 1.0 app will run fine, and the 1.1 app will refuse to run.
You can get a 1.1 app to run on a 1.0 only machine by creating a .config file for the application and have the runtime redirect assembly bindings.
TSWizard_v1.1.zip (28.8 Kb) here is an assembly and a demo application, compiled under .NET 1.1 (you can verify this by running ildasm on the files and seeing that it binds to version 1.0.5500 of the BCL). In the .config file are the appropriate items needed to make it run under v1.0 of the framework.
You can create this .config file by hand *or* take the easy (and less error prone) way out and let the ".NET Framework Configuration" utility do all the work.
James
Sig code stolen from David Wulff
|
|
|
|
|
You can't really say this technical thing to an end-user, can you ?
That's exactly what happens in practice. You double-click on the app, and it fails with a stupid messagebox. No way to fix it.
Now if your words are for developers, you simply expect them to have BOTH run-times installed, tested, and upgrading problems fixed before starting the distribution. This is not exactly what you read in MS marketing brochures when they claim great productivity gains...
That's not exactly what I thought about next gen dev platform. I thought the existing CLR would try to figure out what was missing, start a wizard, and download missing stuff. Automatically, no need of any additional line of code here, since at compile-time you have already told the compiler which versions of assemblies to compile and link against.
In addition, the fact that new regular (one per quarter) .NET run-time comes with new features makes you, the developer, feel like using them. But, and here is the trouble, you cannot really expect the end user to have the same run-time than you, otherwise it requires not only the end user to more or less be an MSDN addict and start downloading all possible updates whenever possible, but the user may be asked to do it without any visible value for it. When you see the sizes of redistribuables (main, and additional), that's really an issue.
Final point, since the .NET run-time is often updated (MS site promotes always the latest, and removes access to older stuff, an amazing habit you don't mention) it's not a point to have the .NET run-time available by default on coming OSes.
How low can you go ?
(MS retrofuck)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
