GRAPHIC attached?

[Peter Jinks]

I know that graphic targets have to be attached using the GRAPHIC ATTACH statement before they can be used, but is there any way to find out which target it is that is currently attached?

I've looked through the help files and searched the forums and can't find anything that does this. Does anyone know if there is such a thing please?

Pete.

[Chris Holbrook]

I don't think so, but you could use a global variable to keep track. Maybe PowerBasic Inc would consider adding the feature, if you could make a convincing case?

[Gary Beene]

I don't think this is the answer you want, but it should work.

Instead of using the hwin/id in the GRAPHIC ATTACH, use global variables.
Then before using GRAPHIC ATTACH, assign the variables to hwin/id of the graphic to be attached. Then the global variables will always have the info you need.

You can make a function out of it to make it simpler.

Global CurrentID as dword
Global CurrenthWin as dword

Function NewAttach (hwin as dword, id as dword)
  CurrentID = id  
  CurrenthWin = hwin
  Graphic Attach CurrenthWin, CurrentID
End Function

I'll poke around a bit more to see if there's a simple lookup that will be easier yet.

[Gary Beene]

As soon as I posted my response, I saw that Chris had commented also. You have to be quick on this forum sometimes.

[Michael Mattias]

I'm sure you have a reason for wanting this, but please explain it.

I'll bet there is 'another way' to learn what it is you are trying to learn.

The only thing which makes sense to me is you want to perform some GRAPHIC XXXX operations in a procedure, in which case all you have to do is pass the current attached hWin to that procedure as a parameter.

i.e, your code looks like

    GRAPHIC ATTACH MyLocalHWin 
    CALL myProcedure (MyLocalhWin) 
.....

FUNCTiON myProcedure (hWin AS LONG) AS LONG
  GRAPHIC HOP hWin, 5 
  GRAPHIC SKIP hWin, 9 
  GRAPHIC JUMP  hWin, 32 
END FUNCTION

MCM

[Peter Jinks]

Thanks for the replies everyone.

@MCM: What I'm thinking of is similar to what you surmised, but the routine itself uses a graphic object of its own and therefore has to attach it. Being a conscientious programmer, I like to leave everything outside the routine that's not directly related to the routine in the same state it was in before the routine was called, particularly if said routine is in a DLL, so I wanted to be able to re-attach the graphic object (if any) that was attached prior to the routine being called.

I realise I could pass two extra parameters to the routine (because it could be a dialog and control ID, not just a graphic window), but that seems an ugly way of achieving it if it's possible to find out what is currently attached with a simple function call.

Still, if there's no way to do it, there's no way to do it. Perhaps I'll send in an NFS.

Thanks anyway.

Pete.

[Michael Mattias]

but the routine itself uses a graphic object of its own and therefore has to attach it. Being a conscientious programmer,

I think I see, your procedure proposes to be

FUNCTION MyFunction 

    SaveAttach  = "some function" 

    GRAPHIC NEW ...
    GRAPHIC RUN, SPOT, RUN 
    GRAPHIC  DESTROY WHAT I CREATED HERE 
    
    GRAPHIC ATTACH SaveAttach  ' restore [I]status quo ante[/I]

Well, passing the currently attached hWin lets you do that.

Unfortunately...
>particularly if said routine is in a DLL

I believe GRAPHIC operations are like DDT operations: you cannot operate on an object (eg ATTACH) unless it was created in the same code module. Someone who knows GRAPHICs better than do I can confirm or refute that.

[Peter Jinks]

I think I see, your procedure proposes to be ...

Yes.

Well, passing the currently attached hWin lets you do that.

Yes I know, although again, it would have to be both the hWin and the ID, because it may be a graphic control. But that's not what I was asking.

I was fully expecting the answer to my question to be "no", but thought it was worth asking in case I'd missed something that someone else had found.

Thanks anyway.

Pete.

[Chris Holbrook]

ISTR some caveat regarding using DDT statements on dialogs in different modules. It might be worth checking with PowerBasic Support that what you are doing is supported.