Subject Re: Closing an image on a form From roy price <royprice@royprice.name> Date Tue, 13 Apr 2021 06:05:12 -0400 Newsgroups dbase.getting-started Mervyn Bick Wrote: > On 2021/04/11 10:06, roy price wrote: > > > Hello Mervyn, > > Well at last I have a (mostly) working example of using three image controls on my tables. As I've added an ID field to my tables so as not to disturb the OnNavigate example ((I've never come across ApplyLocate before, at least long ago when I could remember the commands) > > ApplyLocate() is a method of a rowset object.  It is the equivalent of > the LOCATE command in "old" dBASE.  It searches from the top of the the > image file each time until it finds the required record. It is very > simple to include it in one's code but it can introduce a delay in > selecting the correct record from a very long table.  There are > alternatives but let's worry about this later if it does prove to be  a > problem. > > > I have a couple of problem areas to work through.... > > the opening photo is not correct if the main table and the photo01 file do not start with the same record.... I guess thats an indexing solution. > > and the ID  autoincrement fields on each file will soon be out of sequence as more photos are added (currently changing the photo file to character produces an error, even if the line is changed as suggested). > > In the example I posted I used four copies of the same table.  The > autoinc ID field in the main table was therefore the same as the ID file > in each of the three image tables.  The example did, however, show the > concept of finding the correct record in the correct image file. > > To keep your main file and three image files in step you need two > dedicated fields in the main table.  You already have the photoyesfile > field in the main table to indicate which of the three tables to use. > You also need a field to indicate which record to select in the image > file.  Call it, say, photo_no and make it type LONG.  If you have an > autoinc ID field in each image file you store that number in the > photo_no field.  It doesn't matter that the same number occurs in each > image file.  The value in the photoyesfile makes sure you are looking at > the correct table. > > The code to locate the correct record would then be the following > assuming ID is the autoinc field in the image file and photo_no is the > field in the main table. > >     ....rowset.applyLocate( "id = " + this.fields['photo_no'].value  ) > > You've put quite a lot of work into this but it's not the usual approach > (nor is it the recommended approach) to displaying images on a form. > > If you already have all your photos on the hard drive keeping a second > copy in one of your image tables is simply a waste of disk space.  The > preferred way of dealing with this situation is to have a field in your > main table which contains the path and file name of the relevant photo. >   Let's call the field photo_path.  It needs to be a character field and > it must be wide enough to accept the longest path.  50 characters will > probably be overkill but rather too wide than not big enough. > > If you have stored your photos in the Windows pictures file then save > something like c:\userName\pictures\2020_01\img_1234.jpg  to photo_path. > I have a second harddrive which is used only for data so I would save > something like d:\pictures\2020_01\img_1234.jpg to photo_path. > > Don't assign a value to the image control's datasource property in its > constructor code.  To ensure that the form opens with an image displayed > use the form's form_onOpen event handler. > >     function form_onOpen() >         form.image1.datasource = 'filename ' + > form.datamodulename.queryname.rowset.fields['photo_path'].value >        return > > > To update the image control as the user navigates the table use the > onNavigate event handler. > > >    function rowset_onNavigate(type, nRows) >        this.parent.parent.parent.image1.datasource = 'filename ' + > this.parent.parent.parent.datamodulename.queryname.rowset.fields['photo_path'].value > >        return > > > As you can see, this code is significantly simpler than having to deal > with images stored in a table. > > Mervyn. > > Hello Mervyn, > "If you already have all your photos on the hard drive keeping a second copy in one of your image tables is simply a waste of disk space.  The preferred way of dealing with this situation is to have a field in your main table which contains the path and file name of the relevant photo." Funnily enough, I did use that approach 20 years ago, but then gave away dbase in favour of a spreadsheet, but recently became disillusioned with the spreadsheets inability to cope. Hence back to dbase. I have two synology diskstations of 25TB each, so no problem with diskspace nowadays. Although I remember buying a 2mb hard drive because I could not envisage ever needing the space of a 5mb drive. Regards Roy Price > > > > > > > > >