|
Why do you make that assumption? The OP has not posted anything about that...
|
|
|
|
|
Call it an "educated guess".
|
|
|
|
|
I think this code help you.
RegistryKey KEY = Registry.LocalMachine.OpenSubKey(@"SOFTWARE\Microsoft\Windows NT\CurrentVersion");
string version= KEY.GetValue("ProductName").ToString();
|
|
|
|
|
Hello experts,
I'm currently developing a UserControl in which I have a browseable Image property.
What is the correct approach to dispose this image?
Should my UserControl dispose of it when it gets disposed?
That would create a potential problem if the Image is used elsewhere around the application.
But then again, not doing so means taking the chance that the image is not disposed.
Thanks in advance,
Shy.
|
|
|
|
|
Shy Agam wrote: That would create a potential problem if the Image is used elsewhere around the application.
Only if you used the same instance of the image elsewhere. If you do, I would look to using a weak reference[^] on the image.
Shy Agam wrote: Should my UserControl dispose of it when it gets disposed?
In my opinion, yes.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Hi Pete,
I always have been, and still am, struggling with this question. Here is a simple example:
I create a UserControl that holds a PictureBox;
I create a modal Form holding two such UserControls and some Buttons
Initially the Form loads one image and shows it in both UC.
then:
scenario 1: I press a button and another image gets loaded in one of the UCs (the original image remains in use in the other UC)
scenario 2: I press another button and one UserControl should vanish (the image remains in use in the other UC)
scenario 3: I press yet another button, it closes the Form (the image is no longer referenced).
So who should be calling Image.Dispose()?
It can't be the UC, as it does not "own" the image.
It shouldn't be the Form, as it will be very vulnerable as soon as the use cases get a bit complex.
So we need some pattern here that automates/hides the problem.
FWIW: the problem vanishes if one never assigns the same image to different UCs, which implies each UC shows a different instance of Image (possibly showing the same thing though), but I want to avoid loading the same image twice if I can reliably do so.
And I don't see how a WeakReference will help me; I know how to use them to possibly keep an object alive, as in a user-created cache. However here the PictureBoxes want to be sure they have the image at hand that they are supposed to show, nothing is supposed to be weak here.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
Wow, talk about going way beyond the original problem. Right, here are some thoughts based on work we've done with this in the past.
If you want to show the same image in multiple locations then you don't make the lifetime of the image the responsibility of the items that are showing it. In other words, I'd have an ImageManager class that contained the image. When the controls want the image, then I would return a clone of that image to the control instead - the control can then happily dispose of that image. The lifetime of the ImageManager is then independent of the user control and can be maintained as a WeakReference.
We have used this technique successfully in several projects and it's worked well for us.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Yeah, that is what I was afraid of, another Manager.
Thanks. I was still hoping a ready-made solution existed.
Acutally, you now said it can't be the UC's responsibility. That is a change of heart from before[^]. The UC, being a component, is open to reuse.
Pete O'Hanlon wrote: going way beyond the original problem
curiosity. the ambition to learn. generalization. advancement. you name it.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
Luc Pattyn wrote: another Manager
You can never have enough managers. The UK is proof how well that works.
Luc Pattyn wrote: curiosity. the ambition to learn. generalization. advancement. you name it.
Hoo yeah. I'm almost tempted to write a blog post demonstrating this.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Pete O'Hanlon wrote: I'm almost tempted to write a blog post demonstrating this.
what else do you need?
I'll be reading it!
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
Luc Pattyn wrote: what else do you need?
Time.
Luc Pattyn wrote: I'll be reading it!
Ah. A reader. Excellent.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
I've posted an article demonstrating a simple weak referenced image library that demonstrates what I've been talking about. It's available here[^].
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Hi Pete,
thanks for the notification.
BTW: you may want to check the downloads, they seem pretty empty at the moment.
Regards,
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
What??? Try now - for some reason the article editor put in a borked entry (or two).
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
All is well now. Thanks.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
Shy.
Have a read of the article here[^]. It might help.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Hey guys,
You've helped me a lot before, but once again, I need some hints about how to program something.
Suppose that my application generated 2 arrays of int values:
ModulesOnSurface = {14, 12, 46}
ModulesConnected = {24, 14, 10, 18, 6}
This is only an example. The lengths could be different and so could the values. The sum of the items in ModulesOnSurface is always equal to the sum of the items in ModulesConnected (72 in this case).
The items of ModulesConnected should automatically be assigned to ModulesOnSurface. An item in ModulesConnected can be split and multiple items can be put together. This means there is always a solution, but I need just the one with as few splits as possible.
A possibility in this case is (1 split: 24 to 12+12):
14 = 14
12 = 12 (from 24)
46 = 12 (from 24) + 10 + 18 + 6
This would also be possible but less optimal (2 splits: 24 to 22+2 and 18 to 10+8), so I would like to avoid it as much as possible:
14 = 6 + 8 (from 18)
12 = 10 + 2 (from 24)
46 = 22 (from 24) + 14 + 10 (from 18).
Afterwards, I need to know how everything is assigned. So in the first example I need to know:
24: 12 to surface B and 12 to surface C
14: 14 to surface A
10: 10 to surface C
18: 18 to surface C
6: 6 to surface C
This is a brain breaker. I know how to get the assigning done without the possible splits but now that I can split and need the optimal solution, I'm kind of stuck...
Could someone help me out?
Thanks in advance!
|
|
|
|
|
|
In my opinion, setting the Path of the FileSystemWatcher to an empty string is wrong.
The control is meant for watching a physical folder, so you shold provide it with a path.
If you want to stop watching the current path, you ought to set:
fw2.EnableRaisingEvents = false;
and then reenable it again the next time you provide a valid path.
Good Luck
BTW: Don't cross post! See my other answer in QA...
modified on Thursday, May 20, 2010 4:47 AM
|
|
|
|
|
|
Interesting, in the big whole, you agree with me, and you accept the fact that you cannot clear the path. So why do you vote 1 for my answer which is in fact correct? Don't shoot the messenger...
|
|
|
|
|
|
But that still doesn't warrant a vote of 1 for my reply which is correct.
It's not my fault that MS has done it that way.
As I mentioned: Don't shoot the messenger just because you don't like the message.
|
|
|
|
|
|
EthicsGradient wrote: I don't see any other option.
Don't mark it as any.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|