gif file in use 2

[mejiaks]

Guys

i have a gif file displayed in a form, this form is open 24/7 since it is a time attendance clock

from time to time, Human resources wants to change the gif file, in theory, it it just save the new gif with the same name and the refresh will do the rest.

but when trying to replace the gif file, gives an error cause the gif is in use

any idea on how to avoir this???

 

[Mike Lewis]

Easiest way would be for the new GIF to have a different name from the existing one. Then, after they have created the new GIF, change the Image control's Picture property to the new name.

Alternatively, close the form immediately before they change the GIF, and open it again afterwards. But I'd prefer the first solution, as the user won't be aware of it.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[IlyaRabyy]

Mike,
The problem colleague Mejiaks has is that the form is on 24/7, and H/R want to be able to change the image file without IT intervention (which your approach requires, sorry).

What I would do is:
Add a timer control into this form;
Per Timer event - check if a newer (check the date stamp) file (full path) with the same name, as the one currently in use, appeared in a dedicated directory;
If it did - disconnect the Picture property from the current image file, copy over the newer one and assign it to the Picture property.
Thus, H/R won't interfere with the working program directly - and won't get that "File is in use" error blown on their faces. ;-)

This scenario needs programming, true, but it would be 1-shot-deal only, which, IMHO, is much more preferable than IT getting calls from H/R "Stop you bloody program we need to change the picture!" every so often - wouldn't you agree, colleagues?

HTH.


Regards,

Ilya

 

[mejiaks]

Thanks ilya, that sounds as a fair aproach

 

[Olaf Doschke]

Yes,

I can't add a better thought here, at least I also can't think of a way to both use an excluded image as picture source and then not block it from being replaced. Even if you load the pic into PictureVal here, this will allow to replace the file, but then you also need timer code to update the PictureVal to reflect that file change.

Even the dreaded picture in a general field or blob field will not help it, even if that could be changed in shared access mode, that won't update the display. Plus you would need at least a lightweight image administration app for human resources to be able to change the picture in the data instead of the simpler replacement of a file.

So I'd also go with Ilyas solution.

Bye, Olaf.

 

[foxmuldr2]

What I would do is:
Add a timer control into this form;
Per Timer event - check if a newer (check the date stamp) file (full path) with the same name, as the one currently in use, appeared in a dedicated directory;
If it did - disconnect the Picture property from the current image file, copy over the newer one and assign it to the Picture property.
Thus, H/R won't interfere with the working program directly - and won't get that "File is in use" error blown on their faces. winky smile

This scenario needs programming, true, but it would be 1-shot-deal only, which, IMHO, is much more preferable than IT getting calls from H/R "Stop you bloody program we need to change the picture!" every so often - wouldn't you agree, colleagues?

HTH.

This is a great suggestion. Another is to use a custom DLL, call a dll function from the paint() event which then BitBlt's the previously loaded image onto the form at specified coordinates.

Using this model the bitmap would have been loaded from disk at some point by the DLL (which opened the file, read the data, closed the file), and then on each paint event following a specified interval, check to see if a newer file exists in the file's directory.

Using this method the image file could appear in a common location along with the rest of the app's data and image files, be loaded, edited, saved, and drawn by the DLL directly from there (without needing a separate directory).

This method also works quite well for creating custom class objects without using ActiveX / OLE embedded objects. By maintaining and drawing their bitmap-to-paint in the DLL itself, and by using a backstyle=0, no-border shape object to outline its position (and intercept mouse events), any custom control of any kind can be created and drawn. And this over any window that has an hwnd that can be intercepted.

I used this technique to create a custom grid class for narrow objects that went down two columns on the left, continued from the top down two columns in the middle, and would up back to the top and down two columns on the right, providing a simple way to navigate through a long, yet narrow set of data items. I put a textbox object in the upper-left corner to capture keystrokes and navigate and do user input, and created a small protocol of functions to query if any data had changed, what row and column it was, and what the new values were, etc., allowing even for changed items to appear in a different color until they were saved (if an explicit "save changes" button was in use), and it worked perfectly.

I did this originally in VFP6, and later in 8 and 9.

Best regards,
Rick C. Hodgin

 

[Olaf Doschke]

Yes, a resource DLL will also work here, but that is missing the demand for the ease of replacing a graphic, isn't it? I don't know if it's easier to replace a gif file or to put together a changed resource DLL.

You could also use LOADPICTURE() or even FILETOSTR() to only temporary access the graphic file, set .PictureVal with that and then would again need to refresh the image from time to time via an event or a timer.

If graphics play a central role in a company you might even implement a web service providing images from a centrally administered repository always in synch with legal issues or corporate identity guidelines. But I'd also seal this with a KISS.

Bye, Olaf.

 

[mejiaks]

thanks to all you guys

i already implemented IlyaRabyy suggestion.

since this is a 24/7 form it is implicit the need of at least 1 timer, so i implemented the replacing of the gif there

 

[foxmuldr2]

You could also use LOADPICTURE() or even FILETOSTR() to only temporary access the graphic file, set .PictureVal with that and then would again need to refresh the image from time to time via an event or a timer.

By far the best / easiest suggestion for simply loading a .GIF that changes periodically, copying it to a temp location, then comparing the date on a timer, allowing the original source file to be edited / modified as needed.

The DLL I was suggesting wasn't a resource DLL. It contained custom code to BitBlt the loaded GIF onto the form, as would be captured from the Paint event and the form's HWND, passed as a parameter, along with coordinates of where to BitBlt.

Best regards,
Rick C. Hodgin

 

[NasibKalsi]

Mejiaks:

Make 2 files: may be call it main.gif and second.gif.
user always save under second.gif.

Your program always makes a copy from second.gif to main.gif and then displays it as required (may be with timer).