|
Means to say that when Task manager window is open or have icon in task bar then it gets handle and hide the process
When task manager window is not open it fails and say Task manager not found ,
Please do a try ? it will make clear
Thanks
Regards.
|
|
|
|
|
ok i got it..
U can put a WH_SHELL hook( using SetWindowsHookEx). Then when ever a window is been created, A funtion of ur will be called. U can check if it is Task manager. If so do as said in the Link that I give u..
nave
|
|
|
|
|
Hey there,
I want to be able to drag a line's position with the mouse. This means that I have to re-draw the line on every mouse-move. However, I must then of course erase the previous image of that line. Is there a way in having an XOR type of Pen or something?
Appreciate any comments.
William
-- modified at 8:04 Wednesday 17th May, 2006
|
|
|
|
|
One thing that you can do is that keep the coordinates of the line stored in some variable of POINT type. Then if a user clicks on that screen check if the clicked point falls on the line(You can use Bresenham's algorithm just to check this).IF the clicked point coincides with any point on the line drawn erase the previous line(ie draw a line with what the background color is.) and start drawing a new line or you if want to show the moving effect on the line you will have to do some more work man(similar to dragging).
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
If the line is drawn into the OnDraw/OnPaint function you have an easy work:
simply change into OnMouseMove the line position an then Invalidate().
This will call the draw function that plots the line into the correct position.
An harder work is edit a Bitmap deleting the old line (putting there the default pixel colors) and re-draw the line in a different position.
But probally CDC::bitblt() could help you , because there are many binary and ternary raster operation that you could use.
|
|
|
|
|
I have created the dialog based MFC application and for whatsoever reason, I had to make my main application dialog invisible because of which it is NOT showing me the task bar icon. Can anyone help me in this regard?
Code :
BOOL CMainApplicationDlg::OnInitDialog()
{
**************
ModifyStyleEx(0,WS_EX_APPWINDOW);
CSecDlg Dlg;
Dlg.Domoal();
////
}
using ModifyStyleEx(0,WS_EX_APPWINDOW) didn't work.
This will take me to the second dialog on startup, But taskbar icon will not be created.
|
|
|
|
|
Instead of making the window invisible make the window rectagle as 0,0,0,0
i.e Instead of using ShowWindow( SW_HIDE ) use MoveWindow(0,0,0,0)
nave
|
|
|
|
|
Use ::ShowWindow(SW_HIDE).
Appu..
"If you judge people, you have no time to love them."
|
|
|
|
|
if u use ShowWindow(SW_HIDE). the task bar icon will also disappear.. But he/she want to maintain the icon in the taskbar...
more over Why did u put a :: before the ShowWindow(SW_HIDE).? In that case u have to call the function like
::ShowWindow(hWnd, SW_HIDE)
nave
|
|
|
|
|
Thanks for the quick reply.
But MoveWindow(0,0,0,0); will not solve the problem. It will add the task bar icon but dialog will be invisible because of its 0,0,0,0 dimension. Setting the MoveWindow for the second dialog also will not work. As its dimesion is relative to its parents dimension.
|
|
|
|
|
I didn't understand ur requirment.
u want to create a Dialog.
It should be invisible..
But u want the icon in the taskbar..
This is what I understood. Is that what u mean?If so why u say MoveWindow will not work?
nave
|
|
|
|
|
Yep Naveen.
What you have understood is right. In addition to that I am calling second dialog from the onInitDialog of the main application dialog(Which I don't want to display)
like.
void CMainAppDlg::OnInitDialog()
{
// blah blah blah..
CSecDlg dlg;
dlg.DoModal();
}
So that Second Dialog appears on startup.
So If I write MoveWindow(0,0,0,0) in OnInitDialog of CMainAppDlg
then task bar icon will appear , but even Second dialog also disappers
as its dimension is (0,0,0,0)...And I tried MoveWindow(100,100,100,100)
in OnInitDialog of second dialog But this didn't work as its dimension is
relative to its parents i.e CMainAppDlg in my case. I need to have workaround for this. 
|
|
|
|
|
There is an easy work around for this.. u create the second dialog with desktop as parent..
void CMainAppDlg::OnInitDialog()
{
// blah blah blah..
CSecDlg dlg;
dlg.Create( IDD_SECOND_DIALOG,0)
dlg.RunModalLoop();
}
nave
|
|
|
|
|
My problem has been fixed. Thanx to Naveen and nicenaidu for their quick responses.
Solution:
In the onInitDialog of the second dlg we need to add the code..
BOOL CSecDlg::OnInitDialog()
{
// blah blah
// Show the task bar icon
ModifyStyleEx(0,WS_EX_APPWINDOW);
//blah blah
}
this will work. If you would like to hide the taskbar icon for whatsoever reason then add ModifyStyleEx(WS_EX_APPWINDOW,0); in dialog's onInitDialog function. This information was found in Codeproject, I customized it to suit my requirement.
|
|
|
|
|
ShowWindow(SW_HIDE) will not work because.....once OnInitDialog is completed it will call ShowWindow(SW_SHOW)...So this will not work. I found a work around to hide the dialog in code project...But taskbar icon also disappears along with it.
|
|
|
|
|
I want to encrypt folder don't change files inside the folder。Thanks!
Effort!
|
|
|
|
|
I'm programming a little game, an Asteroids clone. I need to do some collision detection. In order to determine what should happen when two objects collide, I need to know which types of objects they are.
I've got a few different classes, one for the player ship, one for asteroids and another for the bullets that the player can shoot. All of these are children of a base class containing some generic physics code.
I've got a vector of *base_class which keeps track of all objects, meaning that regardless of whether the object is of class ship or class asteroid or whatever, it is stored and accessed through a vector of *base_class.
What I need to do now is to go through this vector and find objects of certain types, i.e. find all asteroids. I could of course just add another member variable and set it accordingly, but I was wondering if there is a way to determine what type of object the pointer is pointing at.
Does anyone have any suggestions?
|
|
|
|
|
I would suggest what you said in your post: add a variable in the base_class that specify which kind of object it is.
To secure the code (so in order to always specify a value for that variable), you can force it through the constructor: remove the default ctor and let only a constructor that supply the type.
Then, in the constructor of your derived classes, in their constructor, simply call the base constructor with the appropriate type.
You can also enable Run-time type information but I don't have a lot of experience with that.
Cédric Moonen
Software developer
Charting control
-- modified at 7:21 Wednesday 17th May, 2006
|
|
|
|
|
All of these solutions based on switching on a type field in the base class are contrary to object oriented principles. If you use inheritance and virtual function properly you shouldn't need such switching. Excessive switching on a type field violates The Open Closed Principle. See here[^] for a good but short article on general object oriented priniciples and The Open Closed Principle.
Steve
|
|
|
|
|
What do you mean by switching ?
Here, there is no casting involved: suppose you have a ResolveCollision function (and you pass the object with which it collides as parameter) that is virtual in the base class, and each child class overrides this method. In these particular functions, you need to know at least what is the type of the other object you are colliding with (because the actions to be taken will be different depending of the type of the other object).
What suggestion do you have for a better design ? I'm curious now .
Cédric Moonen
Software developer
Charting control
|
|
|
|
|
Cedric Moonen wrote: add a variable in the base_class that specify which kind of object it is
This is what I was referring to in my comment.
This article[^] can expliain why I think its probably a bad idea better then I can here. The section on The Open Closed Principle is about such designs and why they're a bad idea.
Steve
|
|
|
|
|
Hi Stephen, thanks for the article, it was interesting.
I totally agree with you on that point but here, a part of the problem is solved by using a virtual ResolveCollision function. Still, there is a need to know with which entity the current entity is colliding with. So, typically what you suggest is the use of RTTI (getting the typeid of the class) ? This will 'separate' the base class from the implementations (a enum in the base class is not required anymore). Is that what you were thinking about ?
Thanks for your answer 
PS: if I'm so interested, it's because I also develop a game in this style and I implemented in the way I described above. But I'm open to better suggestions 
Cédric Moonen
Software developer
Charting control
|
|
|
|
|
I would not use any type of RTTI. First I'd think about the game. For example with collision detection in asteroids the following should be noted:
- Asteroids don't collide with each other.
- Bullets don't collide with each other.
These facts mean we don't have to check every pair of objects for collisions: we only need to test for the following collisions:
- Bullets with asteroids.
- Bullets with the enemy ships.
- Asteroids with asteroids.
- Your ship with asteroids.
- Your ship with bullets.
- Your ship with enemy ship.
These distinctions should be reflected in our design to minimize the amount of work we need to do to detect collisions.
I haven't thought it through, but I'd probably use multiple lists instead on one super list.
Steve
|
|
|
|
|
Stephen Hewitt wrote: I haven't thought it through, but I'd probably use multiple lists instead on one super list.
Mmmhh, I see a big restriction in that way of thinking: what happens if you want to add a new entity type, say 'bonus' (that gives you lives or new weapon) ? Then, you got a problem in your design because you have to manage a new list which can result in a lot of changes in the existing code...
Right now, what we are doing is that we have a factory that can create specific entities. The different entities register themselves in the factory at the program startup (in fact they register their name and a function that create one instance of the entity, so no need to modify the factoty when new entities are added, it's just map names to a creation function). So, if you want to create a new entity type, you just have to create the new class (and the creation function) and register it in the factory at startup and that's done ! No modifications in the rest of the code.
You will tel me: 'Ok, but to be used, these new entites needs to be created so you need to know if they exist or not'. In fact this step is not 'directly' required because the creation of the levels of the game is made through an editor. The editor retrieves the available entities from the factory and allow the end user to place them in the level (so, there also, there is no need to know these entities).
With your design, I see a flaw when you want to add new entity types that were not planned.
Stephen Hewitt wrote: These distinctions should be reflected in our design to minimize the amount of work we need to do to detect collisions.
It's perfectly doable with the method I exposed you: in the ResolveCollision of each entity type, it's up to you to take action on one or several 'collisions type'
PS: I don't want to prove you're wrong, but this is an interesting debate and I'm interested in your opinion.
Cédric Moonen
Software developer
Charting control
|
|
|
|
|
We'll stick with asteroids as that's the original topic. My original comment was against switching on object type, be it by using typeid, dynamic_cast or an enum in a base class. I don't think I need to go over this further given that the article I posted a link to explains it better than I could.
Now let’s get to the collision detection. As I pointed out you need not check for collisions between every pair of object as; for example, bullets can't collide with each other. If you've got n objects there are (n*(n-1))/2 = (n^2-n)/2 pairs to test: so it's probably a good idea to limit the size on n since the growth is quadratic. I admit in a game of asteroids, with today’s computers, you probably need not worry. I would probably use multiple lists as not every aspect of an objects behavior need be determined by it: some aspects can be controlled by its environment. For example, which container it's listed in. This need not be a limitation as you control which objects are added to which lists.
I don't want to get into too much of a debate however, as a lot of this is all theoretical. To really get into it we would need a concrete example to work with and spend some time analyzing it and then contrast different implementation strategies; that's a lot of work to win an argument.
Steve
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
