Do you have the same problem with the same graphics file if you access it on your local hard drive, or only on the zip drive?

I am not asking you to move your graphics to your harddrive permanently - just move one of them so we can differentiate whether the format of the graphics file is the problem or whether accessing iomega zip drive is the problem. In either case, we want to fix the problem as opposed to changing how you permanently use Sesame.

Unfortunately, no that isn't quite enough information. It looks like the graphic file itself is the problem. Can I ask you to send one of these files to support@lantica.com and mark it to my attention. Make sure it is one of the files that always gives you grief.

Also, I assume you are in Runtime (data entry) when this happens, or are you in SDesigner designing the form?

It is a problem in Sesame. We are looking into it.

We found the problem. We broke it when we fixed the problem with Static Pictures not scaling correctly for print. Sorry. 

It's fixed for 1.0.3. Meanwhile, to edit image elements, you can use F6 to just type in the image filename, rather than using the Image Browser.

fYI, after using the f6 workaround for the above bug, it seems the image bug appears worse than we thought.  BMP images are being displayed in the incorrect colors and some images (.bmp and .jpg) dont show up at all.

They work fine in other image viewing programs.

Just FYi. you may have already fixed this bug along with the above glitch.

Thanks,
Steve

Thanks Mark. I'll send them within the next hour.

They should be black/white images. They are 'captures' from a palm pilot used to grab customers signatures for my Invoice app.

The text should be black on a white background. They all show up perfectly in Acdsee image viewer and MS Paint.

Thanks again for your attention and support.

Steve

Quote:



From looking at your files, I see a strangeness in their format. About half the programs I have used will not load them. Two of will them load them, but complain, and one loads them (without complaint) but when writing them changes the format. One loads it, but because of the additional planes, believes it to be a true color image (it isn't).

These are single plane monochrome 32-bit .bmp files. Usually a single plane format is an 8 bit image (in that the 24 bits are not actually used).

That's the bad news. The good news is that loading these into just about any non-microsoft image editing program and then saving it again (as a .bmp) will save it as single plane 8-bit .bmp, or a three plane 24-bit .bmp (either is okay with Sesame). I tried this with the image editors: xnview, Kodak Imaging, and Gimp. Unfortunately, it won't work in MSPaint.

The problem Sesame is having with it is that it sees the other 3 planes worth of data and uses them to set the color. But since they are uninitialized values, they "paint" as odd colors.

I'm not sure how to "fix it" in Sesame. The image is saying, simultaneously, that it is both a monochrome and a 32-color (with alpha channel) image. Do I believe the color depth variable or the number of planes variable? Every program (non-microsoft) that I have tried reports differently about this format. Are there any options you can set on the device about image format?

BTW: The ImageMagick command line tools (for easy batch conversion) are available for Windows.

Mark,

When Sesame tries to display a particular damaged .jpg the server crashes and Unlocking database from the admin panel "Fails" each time. We have to use the Sunlock.exe program.

I have seen Sesame handle slightly damaged images, but this one image crashes Sesame everytime.  My other graphics viewers don't crash while displaying this image, but only show the good portion of the image (top half of the image).

Since Sesame is reacting so severly to this problem, I thought I should let you know. I'll email the image to your attention.


Thanks,

Steve in Texas

Edit: We are using ver 1.0.3

Strange. I got the message "Failed to unlock database" each time I crashed. The SUnlock tool worked fine, though.

I assume that Sesame will handle moderately damaged images, so we will continue on and assume that the one image was an exception.

Thanks again,

Steve in Texas

Steve,

The reason the Server Administration Unlock is working for Mark and not for you is because Mark was running Sesame Client and Sesame Server on one computer. 

This is intentional so that you have to be on the Server to unlock the database. The reasoning behind this is because someone may have the file open locally on the server and unlocking it could be catastrophic.

You have three options to unlock a database when running Client/Server. They are SUnlock, Sesame Stand-Alone on the server, or a Sesame Client on the server itself.