Displaying JPG images

[Keith F Weatherhead]

Fairlight wrote:
> Simon--er, no...it was Don Coleman--said:
> 
>>suggestions.  Ideally, I would prefer a viewer program that I can:
>>
>>Control the size and placement on the desktop
> 
> 
> That's not a problem.
> 
> 
>>Not allow for editing (no MSPaint)
> 
> 
> That's also trivial.
> 
> 
>>Be found by default in the same location on each Windows client (XP & 
>>WIN2000 mostly w/ only a couple 98's)
> 
> 
> Not a problem.
> 
> 
>>Display the image while my fP app. remains the active windows session 
>>(important).  I would not want to have to close each "image" windows 
>>session after each image has been displayed but have that same windows 
>>session display each new image in that same window.
> 
> 
> Not take focus on starup, mmm?  Or at least give it back to the last active
> window prior to invocation?  Hmmmm.  *ponder*
> 
> Reading new images via fresh calls...  *ponder again*  Perhaps possible.
> I'd have to try a few things.
> 
> 
>>Ken suggested using start C:\path\to\file to keep fP in control.  
>>However, when I execute it via @KEY there are two problems I need to 
>>resolve. 
>>1) After the start command is executed the image windows session is the 
>>active session, not the fP session.
> 
> 
> I don't think there's a way around that from within fP.  The problem is
> that the application (whichever would be doing the focus work) needs to
> talk directly to the window manager.  If fP needed to retain focus, it
> would need to do that after SYSTEM returns--reclaim its focus.  If the
> image viewer needs to give focus back...that may or may not be more
> complex, as it may need to determine which application to return focus to
> within the window manager--or at least not grab focus, which I'm not sure
> is even doable inside Windows' wm.  I'd have to research that.
> 
> 
>>2) Each time I execute the @KEY routine a new windows session containing 
>>the image is begun which then has to be manually closed.  I need to have 
>>a single windows session containing the image which is "refreshed" by 
>>each new image.
> 
> 
> MUST be refreshed, or could close the old and open the new?  Hmmm...I think
> I even know a way to accomodate the refreshes.  There may be several ways.
> One might be a client/server model.  Another would be possible in unix, but
> is not in Windows, since (despite it being possible) they -still- haven't
> implemented USER, which -really- should be implemented ASAP.  But I'm at a
> loss as to executing one program repeatedly and only using the one window.
> At least under the window toolkit I'm using.  I know Media Player does it,
> so I know it's possible.  Ditto WinAmp.  It's possible in win32, but darned
> if I can immediately think of how it'd be implemented.  This'd take some
> thought.
> 
> 
>>Don't know if this is possible or not.
> 
> 
> Oh, it's undoubtedly possible to get the refresh, one way or another.  The
> focus model may also be doable.  I know I have -some- application around
> here that temporarily gains focus and gives it back.  I just have to figure
> out which one and figure out how it works.
> 
> Offhand, I can't think of anything prepackaged that fits the bill for your
> needs.  Everything either does multiple instantiations or steals focus--or
> both in 99% of the cases.  And that covers over a decade of using various
> graphics software.  Most of which -would- also allow editing and all that
> lot, which is undesirable, as agreed upon.
> 
> I dunno.  What would this be worth to you?  :)  Seriously, if I were to
> code it, given the constraints imposed on the program, it would exceed
> "public service" limits of charity, sorry.  I'd imagine that others around
> here might want to pick it up, but I've made that assumption before and
> been wrong, unfortunately.  An idea of audience size and rough worth would
> help in evaluating whether it's even worth considering further, and under
> what terms.
> 
> mark->

Maybe version one could be a little clunky while better methods are 
researched.  If you had to "re-focus one time" rather than every 
time.  If this is on a single-user *workstation*, rather than the 
server itself, why not copy the *.jpg to a working name passed to 
the viewer so that the viewer opens the file by a TEMP name.

When a new image is desired, simply copy that image over the TEMP 
and and "touch" the file.  If the viewer sees a different date/time 
(should be atleast one second different from the previous image) it 
could grab and display and save the new file date/time.  Have the 
viewer keep retrieving the files date/time looking for changes. 
Maybe that along with the TEMP filename should be a command line 
parameter.

Real cheap, not glamorous, but would get the desired effect and on a 
single user workstation shouldn't even be noticeable either.

Regards,
Keith
------

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
Keith F. Weatherhead                   keithw at ddltd.com

Discus Data, LTD                  Voice: (815) 237-8467
3465 S Carbon Hill Rd               Fax: (815) 237-8641
Braceville, IL  60407       Nat'l_Pager: (815) 768-8098
- - - - - - - - - - - - - - - - - - - - - - - - - - - -