@xyuxux wrote:
I am checking the rc codes for DSM_Entry. All are returning success.
just checking, I thought you might be, but I was curious. The code makes more sense now – thankyou.
To retrieve the twState at that time, I can pass &AppID for the 2nd argument, right?
not the cc, the twState. You see it referenced all over in the spec – look at any of the pages that describe a triplet and there is a line that reads ‘Valid States’. There unfortunately isn’t a twain call to determine the state you’re in – at least that I can find. It’s one of those things that some people track so that they can know whether it is appropriate to do x. In my case I have a member variable and whenever I make a call to twain that is described as changing the twState I update the variable appropriatly depending on the result of the call. It is somewhat tedious but occationally it helps me understand where a call would have been correct according to the spec and when it should have failed according to the spec. Not required by any means but occationally very helpful.
With Twacker, after returning 0 in response to DG_CONTROL / DAT_PENDINGXFERS / MSG_ENDXFER, the wrapper’s UI closes, so it ends normally without having to send MSG_CLOSEDSREQ. So I cannot reproduce the problem.
if it isn’t broken in twacker then I would guess (and maybe bet heavily on) this being a problem with the ‘other program’ – photoshop in this case. And now that I’m thinking of it, I seem to remember someone else writing something about photoshop acting oddly. search thur the forum for photoshop – the only I remember were a couple of posts indication that ps really wanted one xfer mode or another, but you aren’t the first perosn to mention them acting differently than the rest.
then, do (can)you log all of the triplets that the app sends and compare what photoshop is sending vs. what IrfanView, gimp and twacker_32 are calling? it seems more likely that photoshop isn’t placing a call that the rest are. My my world, when I get a closeDsReq from a source I do a couple of things:
TwState = 5; // update my internal twState member
Control.UserInterface.DisableDs // takes twState from 5 -> 4
Control. I d e n t i t y .CloseDS() // takes twState from 4 -> 3
Control.Parent.CloseDsm() //takes twState 3 -> 2
// kill the thread that maintains the independant messageloop
StopMessageLoop();
If you log all the calls from photoshop it may be that they aren’t calling all or some of them but regardless (on some level) last part (the actual problem part) is seems odd to me – maybe it’s just my (mis)understanding of writing a ds that works real well (or at all) or odd bits of c++ that continue to plague me but,
the Ui that won’t close, it is yours. You try asking the dsm to close it and (when photoshop is the app) you get a failure from the dsm. Why don’t you close it yourself?
After returning Count = 0 for DG_CONTROL / DAT_PENDINGXFERS / MSG_ENDXFER and maybe after waiting for DG_CONTROL / DAT_NULL / MSG_CLOSEDSREQ notifications are sent,
Couldn’t you just call DestroyWindow(hwnd) in the event that the DSM returns failure?
And then I re-read your post (yeah, I’m slow) and the thought came to me – wtf!? (I still beleive in the points I made above, but in review this is odder than I originally thought)
You call CloseDsReq before you call openDsm? Wahuh? The next thought that comes to mind is, how long did that take to figure out?
So. (man what a mess) there are basically 2 active sessions with the dsm that are open. 1 from the calling app(gimp, photoshot,etc), that in turn gets your ds loaded, then you begin calling into the dsm again. I might have missed your answer to this but, Where does your handle come from? Are you inheriting from or deriving a class from NativeWindow or CWnd or ..? Are you sure that the messagepump is still pumping?
It seems to me that either your pump isn’t pumping or.. ok I don’t have an or.
.