|
Does anybody has an idea about the slide sorter in power point. The items inside the slide sorter are thumbnail or an actual live controls that contains different types of shape objects. The reason is that i created 200 slides and when i opend the file it opens instantly. I want to know how powerpoint manages this kind of performance if they are are thumnail images or Controls
Thanks for replying
|
|
|
|
|
I would suspect it uses precached thumbnails. As I don't work on the Powerpoint team, this is just my guess however but it does seem likely.
|
|
|
|
|
Thanks for answering and too bad for me you that you aren't in their team. So you think that each time when we move a shape on the screen a thumnail image is created again for that item in slide sorter. Moreover, what about when we type a word does slide sorter recreate a thumnail.
|
|
|
|
|
netJP12L wrote: Moreover, what about when we type a word does slide sorter recreate a thumnail.
Possibly, and maybe probably.
|
|
|
|
|
I was reading an interesting article[^] in Dr Dobbs on event based architectures. In the article, the author describes an architecture in which objects are almost completely decoupled from each other. This is done through events. Say you have object A that raises an event. Object B is interested in this event. A third party called a binder binds these two objects together without either one of them knowing about the other.
This can be easily accomplished in C# using events and delegates.
public Binder()
{
a = new A();
b = new B();
a.SomethingHappened += b.HandleSomethingHappened;
}
However, in playing around with this type of approach, I've noticed that it may not scale well. The problem is that the binder object has all of the responsibility of connecting the dots. This can lead to a ton of configuration code (usually in the binder class's constructor), and it's easy to forget to hook everything up. "Oops! I forgot to hook B to A or was it B to C?" That sort of thing.
So I've considered modifying the approach in which each class knows what events it needs to hook to; it does so by taking an object passed to its constructor and hooking to the relevant events. This approach involves greater coupling. The target of an event knows about the sender. But on the other hand, it relieves the "binder" object of having to know how to hook everything up. All it's responsible for is passing the event raising object to the receiver.
public Binder()
{
a = new A();
b = new B(a);
}
public B(A a)
{
a.SomethingHappened += HandleSomethingHappened;
}
This also has the advantage of giving B the option of making the method responsible for handling the event private or protected so that it's hidden from the outside world.
We can minimize the coupling by using interfaces that expose only specific parts of a class's overall functionality. Then only a reference to the interface is passed to the target class thus limiting its knowledge of the event raiser.
Thoughts?
|
|
|
|
|
If you're interested in loose coupling in your design, I would definitely take a look into Dependency Injection. BTW - what you described initially sounds to me like a variation on the Mediator pattern.
|
|
|
|
|
Pete O'Hanlon wrote: I would definitely take a look into Dependency Injection
I did a search and found Martin Fowler's article on Dependency Injection.[^] Iteresting read.
My situation is similar but not exactly the same to that described in the article, but I think the principle is still applicable, more or less.
Basically, I have one class that offers a set of services, mainly simple notifications when certain things happen within the application. Next, I have a group of class's that use these services. Which services are used can vary from class to class.
The problem I run into is when I start trying to manually wire things up. So I've got my Service over here and my Clients over here, and I have to remember which services a client needs when wiring them together.
The solution that I've settled on is to pass the Service to each Client when it is created. Then the Client can subscribe to those services it needs. The containing class, the one containing all of the Clients, doesn't have to know how to hook up Clients to the Service; it just pass the Service along.
I think I like this solution. It has greater coupling in that Clients are familiar with the Service, but this can be mitigated by hiding the Service behind an interface, which I think is what Dependency Injection does, more or less.
Anyway, thanks for the reply. I'd heard of Dependency Inversion but not Dependency Injection.
|
|
|
|
|
|
I've already seen your article. There's no need to spam it.  And I've done a lot of Dependency Injection, so I don't need a link to an article on it, hence the reason I recommended it.
|
|
|
|
|
Pete,
May be I was not very clear . Actually not only I agreed with your opinion, but I meant to add into your concise reply by informing Lelie who wrote "I'd heard of Dependency Inversion but not Dependency Injection", that is why I referred to a link! Perhaps it was"Inversion of Control"  that was intended.
Fakher Halim
modified on Thursday, July 17, 2008 4:00 PM
|
|
|
|
|
Fakher Halim wrote: Perhaps you meant "Inversion of Control"
Nope - I meant Dependency Injection, as featured in my original post, and which he found in his search. Anyway, no harm done.
|
|
|
|
|
Thanks!! it should be just a typo! 
Fakher Halim
|
|
|
|
|
Pete O'Hanlon wrote: BTW - what you described initially sounds to me like a variation on the Mediator pattern.
You mean this initial statement?
Leslie Sanford wrote: I was reading
led mike
|
|
|
|
|
led mike wrote: You mean this initial statement?
Leslie Sanford wrote:
I was reading
|
|
|
|
|
Good morning!!
What's the design pattern whereby you have to go through a certain class to get an instance of another?
E.G,
I have a class called Devices, and classes Valve, PID, ControlVlv and Pump.
I don't want to be able to instantiate Valve, Pump etc without going through Devices (which will return a collection of said classes).
But I want to be able to use said classes throughout the app.
Does that make sense?
I'm sure I've done it before....
Thanks,
|
|
|
|
|
Hi,
sounds like a Factory to me.
|
|
|
|
|
Ye ah I thought that, just can't seem to find the right one!
|
|
|
|
|
You've got the right surname to be talking about patterns.  Sounds like you need to consider using something like the Abstract Factory pattern.
|
|
|
|
|
This one has puzzled me before.
Valves, pumps, and the like sound very concrete, yet they want to call it an abstract factory?
|
|
|
|
|
I know. It's a really crappy name. Really really crappy.
|
|
|
|
|
|
Nooooo. It is a good name, though just as good and maybe better would be static factory. The factory itself is usually a class with only static methods, so it should be static (or abstract, though static is perhaps the more academically pleasing choice since it's not intended as a base class for concrete factories but rather just a bunch of static members relating to the same thing). So even though the products of the factory are concrete, the factory itself isn't.
Pump p = Factory.CreatePump(...);
not
Factory f = new Factory();
Pump p = f.CreatePump(...);
Normalement.
|
|
|
|
|
This[^] message explains my problem with the name. I prefer the static name you suggest though - it sounds better.
|
|
|
|
|
Luc Pattyn wrote: yet they want to call it an abstract factory?
What are you guys talking about? Isn't the pattern supposed to use the implementation of an abstract class for the factory and the user derives from it implementing the concrete factories? Or am I not remembering the pattern correctly?
led mike
|
|
|
|
|
You are remembering it correctly. It's just a name that I have a problem with just because it sounds like you can directly instantiate abstract classes. I'm not sure what they should call it, but I've had staff being confused about this when they complain about their code not working because it's abstract.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
