Quote:Original post by steven katic
Is The Question going where no man has been before?

To me it seems so.

but I don't know, it just seems really difficult (working inside out... from graphics API to [hooking to] windows forms API etc).

(1)I would have started this as/with a windows form application.
Did you? Can you? It seems as if that was your original aim, what happened?
(2)Then custom skinned it(how do you do that? : research)
(3)Then Applied the graphics API (directx/opengl) to a Control ( e.g. Forms::Panel is a good one).
(4) Find out if 2 and 3 above compatible?

Bit like a sandbox or game/model/terrain editing tool?

Do you see that as possible?
Would you consider:
Can you/have you modularized you existing code enough to be able to create your app as a windows form application? Its just that I think if you could, then you would have a well known/used/understood base on which to continue to build your app with tons of typical ref material.

I don't think I have really answered your question but...its just that if you are not beyond the point of no return you could do (1) to (4) above and perhaps avoid what seems to be a difficult path.
Maybe you have already looked at (1) to (4) already deemed it not viable?

or maybe I do not quite understand your aim:
Is it to make you own version of an xfire type application?

You even confused me more lol:) I am not trying to do what xfire does. Why would I waste my time for something that is already out there:). But because what I am doing is so complex and hard to explain, the best example/the closest example to what I am doing is xfire. Like they do, I have to show my form, but instead of typing messages in it, I will show graphs, statistics (CPU temperature/GPU Temperature, etc).

You think this is hard? Try getting the RDMSR instruction to execute to get CPU temperature, then try getting PCI bus information for GPU temperature, and about 55 other things (information) about hardware:) (This is phase 1), then also try writing a hook that will never crash, but will hook into any game for dx8,dx9,ogl,dx10, both 32 bit and 64 bit, both XP and Vista compatible:) (This is phase 2). I did both 1 and 2 in about 4 months, I believe after what I saw in there, nothing is impossible:)

Now I'm in phase 3, show a window, very simple window, in a game:)

There has got to be a way, come on, if Columbus said "too hard", what would we do?:)

yeah...I would love to hear from someone that has a robust example or solution too!
More curious would be the reason given for such a rare/unusual approach
The rare/unusual approach could be given as an explanation for the lack of responses that concerns you so far: Re:

Quote:
Edit: I also want to ask that why out of 173 views in this topic only 1 person responded?...
...The question is, is this method efficient? Is it widely used? and more importantly is it a good way to go?...

in the meantime...
using xfire as an example as you do...I must have misled myself.

I guess the impression xfire gives me is much more simple than the one it gives you: The evidence suggests it to be a standalone app [with typical custom skin(s)] that has no direct connection to any game or application on your system. It interogates the system info(a little like task manager) and the internet data packets sent to your computer for all the stuff it needs/shows. ?

Is there evidence to the contrary?

[Edited by - steven katic on December 7, 2007 9:37:17 PM]

Quote:Original post by steven katic
yeah...I would love to hear from someone that has a robust example or solution too!
More curious would be the reason given for such a rare/unusual approach
The rare/unusual approach could be given as an explanation for the lack of responses that concerns you so far: Re:

Quote:
Edit: I also want to ask that why out of 173 views in this topic only 1 person responded?...
...The question is, is this method efficient? Is it widely used? and more importantly is it a good way to go?...

in the meantime...
using xfire as an example as you do...I must have misled myself.

I guess the impression xfire gives me is much more simple than the one it gives you: The evidence suggests it to be a standalone app [with typical custom skin(s)] that has no direct connection to any game or application on your system. It interogates the system info(a little like task manager) and the internet data packets sent to your computer for all the stuff it needs/shows. ?

Is there evidence to the contrary?

Xfire uses a CBT global system wide hook to hook into every single process and injects in xfire_touchanXXXXX.dll file. You can do a simple listdlls on xfire.exe and see it yourself.

It then hooks into DirectX api and patches the Reset() function within DirectX for games to detect the event of a device lost/alt+tab to set/get focus.

I know about the Reset() function hook because I was hooking into the same function and everytime I start my program It'd crash if xfire or fraps was running. Doing a bit research showed that both Fraps and Xfire do the same thing.

However I don't know whether xfire uses DirectX API to draw on the screen or not, but I highly doubt that they do that. If you ever used it, you'd understand it's a simple skinned winform. In fact, if you set the skin to Default in xfire, you will end up (within the game itself) with a simple windows form.

I have no idea how they are doing it, in fact I don't want to know how they are doing it, I want to learn myself. But for me to learn, I need to have a starting point. The question is not which library to use or what to draw, the question is how to do it.

So if you were a DirectX game programmer, and your boss gave you a task that included creating a child MDI window within the game (like asking for password) which benefits from current windows controls such as listboxes or textboxes, you are telling me it's hard to do? It's really not making sense, I thought this stuff would be very trivial.

Quote:
you are telling me it's hard to do? It's really not making sense, I thought this stuff would be very trivial.

sounds like frustration to me.
We always want thing to be easy, that's natural, and I agree, you would think that it would be trivial at first thought. But as time goes by...

(1)The problem reminds me of 'hacks', or more respectably 'solutions', that were invented to call/derive/have bits and pieces of MFC in a win32 app. The brittleness/interoperability problems seem to be similar.

Just because a solution may be possible and works doesn't mean that it will not work at some stage (or break very easily). We all want a robust/reliable solutions, otherwise....what?

(1) above would not be an acceptable long term solution in my software
(There was a time when I have been oblidged to do it commercially).

Commercially, (1) has been a solution, where timeliness takes priority over quality ( quality being still a monumental problem to be solved in the software engineering industry on the whole)

Anyhow, enough useless waffle, I have been researching for you (how 'bout that?)...no not really...I am just curious to see if the idea in (1) above can be confirmed in my mind (yes, my hidden agenda is not so...er... hidden).

Two things that may interest you (that I hope you can see as significant) are:

http://www.ddj.com/windows/184406078

and maybe:

http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.dotnet.framework.windowsforms&tid=60c9aa39-c949-460d-80b5-feb59c35d758&p=1

[too lazy to link]

You could do more/up-to-date research with better results.

Quote:
...you are telling me it's hard to do? It's really not making sense, I thought this stuff would be very trivial.

Well, if it were trivial, the first reply would have contained a solution(unless people are willingly not helping you - I cannot imagine you have that many enemies ;))

But you seemed to imply that was not likely (?).. when you opened the thread with:

Quote:
I have a very simple question but possibly with a very complex answer....

Quote:
So if you were a DirectX game programmer, and your boss gave you a task that included creating a child MDI window within the game (like asking for password) which benefits from current windows controls such as listboxes or textboxes,

I think I've made my position quite clear without a response to that scenario; it would cause me to contribute more useless waffle to the thread.

What we want is a solution:
Come on someone... show us a good robust,... trivial solution!

I keep imagining it happening because then I do not have to think about your thread and saying to myself "quick get out of the hole you are digging before it gets too deep to climb out...and... grab that rope ladder (long enough) if you are game enough to go back in.

In the meantime hope...and hopefully not in vain.

Cheers

[Edited by - steven katic on December 9, 2007 3:47:54 AM]

Just an update on this, the only way to do this is DDRAW overlays. There is no other "general" way to do it. It's just not possible. 3 days of non stop research also helps.

Basically it all goes down to this:

1. Make a general overlay library, overlay your winform and update it.
2. Make a separate GUI for every single interface - dx8,dx9,opengl32,dx10.

Obviously nobody wants to do #2.

I already saw several examples of overlays but unfortunately most of them don't work, the ones that do are not stable and the library they use (DDRAW) is very very very old. This'll be a very tough one, but we'll see.