Clearing or Refreshing Cached Images?

vining

How do you go about clearing or refreshing images cached in a TP. In a program I'm working on for radar images I have the ability to change the viewed radar type (see attached). Because of the refresh issues of images not in focus despite the use of the ^RFRP command I chose to display small pics of the individual states and one large image of the current state so when I make changes all states are in focus and everything updates. This seems to work very well cuz when I push a button for a different radar type everything on this page refreshes (changes) in 3-5 seconds which I think is great. However although these images all refresh when I run the animation in the large center image area I'll get the last state displayed which shortly there after updates, so on and so forth. Once it makes this first pass and I run the animation again its fine. So how do I initially purge the old cached larger images since obviously the resource manager has been updated when the little pictures refresh so it's got to be the cached images that aren't getting refreshed or updated.

This is the function I'm using to initially change and refreshed everything on the page:

DEFINE_FUNCTION fnChangeRadImageType()
     
     {
     STACK_VAR INTEGER nRadPicIndx  ;
     STACK_VAR CHAR cRadTPResource[9]  ;
			      
     for(nRadPicIndx = 0 ; nRadPicIndx <= NUM_ANI_RAD_PICS ; nRadPicIndx ++)
	  {
	  cRadTPResource = "'Ani_Rad_',itoa(nRadPicIndx)" ;
	  SEND_COMMAND dvActiveTP,"'^RMF-',cRadTPResource,',&#37;Aridge/lite/',
			      Rad_Image_Type[nGetRadImageIndx],'%F',cGetRadRegion,'_',itoa(nRadPicIndx),'.png'" ; 
	  SEND_COMMAND dvActiveTP,"cRefreshCMD,cRadTPResource" ;
	  }//cRefreshCMD = ^RFRP-
     }

This seems to work perfect although I thought I'd need delays between send_commands but it appears I don't.

Once this refreshes the TP, around 3-5 seconds and I then push the animate button I run this funky function which stacks waits in order to refresh the large images as they are called. This was an attempt to fix the larger images that didn't get refreshed by the first function. With this function if this is the first time this radar type animation has run I send ^RFRP prior to the SEND_LEVEL which steps the animation and ^RFR just after when it should be in focus. On subsequent animation of the same radar type I simply step the levels.

DEFINE_FUNCTION fnAnimateRadar() 

     {//
     LOCAL_VAR INTEGER nLstRadImageIndx ;
     
     if(nLstRadImageIndx == nGetRadImageIndx)
	  {
	  SEND_LEVEL dvActiveTP, 1, 8 ;
	  WAIT 12
	  SEND_LEVEL dvActiveTP, 1, 7 ;
	  WAIT 24
	  SEND_LEVEL dvActiveTP, 1, 6 ;
	  WAIT 36
	  SEND_LEVEL dvActiveTP, 1, 5 ;
	  WAIT 48
	  SEND_LEVEL dvActiveTP, 1, 4 ;
	  WAIT 60
	  SEND_LEVEL dvActiveTP, 1, 3 ;
	  WAIT 72
	  SEND_LEVEL dvActiveTP, 1, 2 ;
	  WAIT 84
	  SEND_LEVEL dvActiveTP, 1, 1 ;
	  }
     else
	  {
	  nLstRadImageIndx = nGetRadImageIndx ;
	  SEND_COMMAND dvActiveTP,'^RFRP-Ani_Rad_7' ;
	  WAIT 2
	  SEND_LEVEL dvActiveTP, 1, 8 ;
	  WAIT 4
	  SEND_COMMAND dvActiveTP,'^RFR-Ani_Rad_7' ;
	   
	  WAIT 16
	  SEND_COMMAND dvActiveTP,'^RFRP-Ani_Rad_6' ;
	  WAIT 18
	  SEND_LEVEL dvActiveTP, 1, 7 ;
	  WAIT 20
	  SEND_COMMAND dvActiveTP,'^RFR-Ani_Rad_6' ;
	 
	  WAIT 32
	  SEND_COMMAND dvActiveTP,'^RFRP-Ani_Rad_5' ;
	  WAIT 34
	  SEND_LEVEL dvActiveTP, 1, 6 ;
	  WAIT 36
	  SEND_COMMAND dvActiveTP,'^RFR-Ani_Rad_5' ;
	  
	  WAIT 48
	  SEND_COMMAND dvActiveTP,'^RFRP-Ani_Rad_4' ;
	  WAIT 50
	  SEND_LEVEL dvActiveTP, 1, 5 ;
	  WAIT 52
	  SEND_COMMAND dvActiveTP,'^RFR-Ani_Rad_4' ;
	  
	  WAIT 64
	  SEND_COMMAND dvActiveTP,'^RFRP-Ani_Rad_3' ;
	  WAIT 66
	  SEND_LEVEL dvActiveTP, 1, 4 ;
	  WAIT 68
	  SEND_COMMAND dvActiveTP,'^RFR-Ani_Rad_3' ;
	  
	  WAIT 80
	  SEND_COMMAND dvActiveTP,'^RFRP-Ani_Rad_2' ;
	  WAIT 82
	  SEND_LEVEL dvActiveTP, 1, 3 ;
	  WAIT 84
	  SEND_COMMAND dvActiveTP,'^RFR-Ani_Rad_2' ;
	   
	  WAIT 96
	  SEND_COMMAND dvActiveTP,'^RFRP-Ani_Rad_1' ;
	  WAIT 98
	  SEND_LEVEL dvActiveTP, 1, 2 ;
	  WAIT 100
	  SEND_COMMAND dvActiveTP,'^RFR-Ani_Rad_1' ;
	   
	  WAIT 112
	  SEND_COMMAND dvActiveTP,'^RFRP-Ani_Rad_0' ;
	  WAIT 114
	  SEND_LEVEL dvActiveTP, 1, 1 ;
	  WAIT 116
	  SEND_COMMAND dvActiveTP,'^RFR-Ani_Rad_0' ;
	  }
     }

When this runs for the first time after I change the radar type I'll first get the cached images and they will refesh as they are displayed shortly after they appear and once all steps are complete and I run it again the animation nice and smooth as intended. ( Excuse the stacked waits but as I said this was just a quick attempt to fix the problem although a timeline would have made timing changes much easier.)

There's got to be a way to either eliminate the cached images or refresh them w/o displaying them in full size to do so. Obviously displaying small pictures of each dynamic resource didn't do the trick as I expected.

Any ideas?

ericmedley

I have to admit that I've stuggled with this kind of thing for quite some time on and off. I also display weather radar images and radar animation loops. I've banged around with the whole refresh thing for quite some time and just gave up on it in frustration.

My general feeling is that the whole image refresh thing doesn't quite work as advertised. I've just gotten used to the fact that the image will refresh when the client calls the popup up. So, there will be this momentary blink that they see.

I've also ran into the same thing with other image refresh routines. I stored background images on the master and would change them periodically. In most cases, they work for a while but the panels eventually begin to just ignore the commands and land on one image.

I've never really gone much further with it since it is not a huge priority. One of these days when I've got a spare couple days time to really dig into it, I will see if I can nail down what's going on.

vining

Well adding a SEND_COMMAND for the ^BMP- function seems to have fixed the cached image problem.

DEFINE_FUNCTION fnChangeRadImageType()
     
     {
     STACK_VAR INTEGER nRadPicIndx  ;
     STACK_VAR CHAR cRadTPResource[9]  ;
			      
     for(nRadPicIndx = NUM_ANI_RAD_PICS ; nRadPicIndx >= 1 ; nRadPicIndx --)
	  {
	  cRadTPResource = "'Ani_Rad_',itoa(nRadPicIndx - 1)" ;
	  SEND_COMMAND dvActiveTP,"'^RMF-',cRadTPResource,',%Aridge/lite/',
			      Rad_Image_Type[nGetRadImageIndx],'%F',cGetRadRegion,'_',itoa(nRadPicIndx - 1),'.png'" ; 
	  SEND_COMMAND dvActiveTP,"'^RFRP-',cRadTPResource" ;
	  SEND_COMMAND dvActiveTP,"'^BMP-1,',itoa(nRadPicIndx),',',cRadTPResource" ;
	  SEND_LEVEL   dvActiveTP,1, nRadPicIndx ;
	  SEND_COMMAND dvActiveTP,"'^RFR-',cRadTPResource" ;
	  }
     }

This works pretty well, gets the new images for the updated URL and downloads and refreshes in 3-5 seconds and then when I run the animation I don't have the problem with the old cached images.

I thought it might be better to slow it down some and make it more reliable even though I don't really have a problem with it so I created a recursive function which waits before calling itself again but much to my suprise this made things worse, actually about the same as before I added the ^BMP command. Now I'm confused. I thought for sure it would be better not worse.

DEFINE_FUNCTION fnChangeRadImageType()

     {
     fnDoRadarUpdate(NUM_ANI_RAD_PICS) ;
     }

DEFINE_FUNCTION fnDoRadarUpdate(INTEGER iRadarIndx)

     {
     SEND_COMMAND dvActiveTP,"'^RMF-Ani_Rad_',itoa(iRadarIndx -1),',%Aridge/lite/',
			      Rad_Image_Type[nGetRadImageIndx],'%F',cGetRadRegion,'_',itoa(iRadarIndx - 1),'.png'" ; 
     SEND_COMMAND dvActiveTP,"'^RFRP-Ani_Rad_',itoa(iRadarIndx - 1 )" ;
     SEND_COMMAND dvActiveTP,"'^BMP-1,',itoa(iRadarIndx),',Ani_Rad_',itoa(iRadarIndx - 1)" ;
     SEND_LEVEL   dvActiveTP, 1, iRadarIndx ;
     SEND_COMMAND dvActiveTP,"'^RFR-Ani_Rad_',itoa(iRadarIndx - 1)" ;
     
     if(iRadarIndx > 1)
	  {
	  WAIT 5
	       {
	       fnDoRadarUpdate(iRadarIndx - 1)
	       }
	  }
     else
	  {
	  RETURN ;
	  }
     }

As seen in notifications this sends the commands just as the first function but at a slower rate. Why would slower be worse than the rapid firing for loop.

Just call me confused!