Jump to content

Drag and Drop images into containers on Mac. PCT files dont' work for me.


This topic is 6236 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

On Mac, when we drag and drop an image from a web page into a container field in FM it puts it in there as Untitled.pct. I have a PHP script that pulls the image from the container field and FTP's it to our web server. The problem is it doesn't work for .pct files.

If we actually save the file from the web site to the disk and then right click on the container and add (speaking of which, is there a script step that will allow me to just click on the container field to add an image?) then it works fine because it saves the image as the actual file format.

On windows it works fine too because when you drag and drop it saves as .bmp which then works fine when I rename to .jpg and FTP.

The .pct files just end up as broken images when I rename to .jpg and FTP them.

Any ideas on how to get around this would be greatly appreciated. Thanks!

Posted

I just tried dragging an image from Safari into a container field and was amazed that it worked at all. Why does FileMaker not allow drag and drop into container fields from the desktop, Finder, etc.?

Posted

Apple has deprecated the PICT file format as of Mac OS X 10.3 and FMP no longer supports the format as of FMP 7. PNG, PDF, and JPG are the preferred formats moving forward.

Posted

Ugh, now it's acting completely different on Windows and isn't even working with the drag-n-drop part.

Now when I drag a picture into the container in FM I get the dialog I've attached. No matter which one I select it pops up trying to save a new converted .fp7 file. :):)

This was working perfectly on this same machine just yesterday. Still works fine on my Mac connected to the same files except that it uses the .pct format.

01.jpg

Posted

Ok, I've still got weird issues on this one windows machien with drag n drop, however, I've discovered that right clicking on an image in a browser and selecting copy, then pasting into the container field in FM it actually holds the actual image format. I got all excited thinking this would work on Mac too....no chance.

Mac still uses .pct even when I copy/paste the image instead of drag n drop. So the ONLY way I can make this work on Mac is to actually save the imaeg to the local disk and then add it into the container field manually...??

all the people in Mac forums are telling me this is a FM problem because .pct isn't used anymore. I'm using FMPA9. Any way to turn off the use of .pct..:)

Posted (edited)

How about this...is there a function in FM that I can use to look at the current filename/type in the container field? Then I could at least check the extension for .pct and that's what it is I could throw a message explaining the picture is invalid. Then I'll just have to explain to my client that they'll have to go through saving the image to their disc and then adding it into FM when working on a Mac.

Edited by Guest
Posted

How about this...is there a function in FM that I can use to look at the current filename/type in the container field? Then I could at least check the extension for .pct and that's what it is I could throw a message explaining the picture is invalid. Then I'll just have to explain to my client that they'll have to go through saving the image to their disc and then adding it into FM when working on a Mac.

It looks like a FileMaker issue. Report it as a bug.

The best way to get pictures from the web into FMP is to save the image to disk and then insert the image using the "Insert > Picture..." command.

Posted

Actually, I used a support code to call and talk with somebody at FileMaker. I wound up teaching him how to use the drag n drop feature to begin with. He was excited and shocked that you could even do that.

Then I went on to explain the problem with .pct and how all the Mac users I talk to say it's deprecated and shouldn't be used anymore, etc...he tells me it's a Mac problem because when you drag and drop or copy paste it just uses whatever is on the clipboard. Apparently OSX Leopard is STILL using .pct as their format for images on the clipboard even though they claim it's been replaced with .png.

Posted

And now I've got people in Mac forums telling me the default clipboard format is PDF. So, as with all of my Mac problems, I'm getting the run-around instead of an answer. :)

Posted

Yeah, I don't know about Leopard, but in Tiger an image on the clipboard is definitely PICT. AppleScript:

tell application "Finder"

set x to the clipboard

end tell

Returns:

{picture:«data PICT...lots more of picture data

Yes, you can Insert from a file and FileMaker preserves the format. But it does seem odd that the Mac Finder can't preserve the format onto the clipboard.

So there doesn't seem to be a way you can control that format when Mac users drag and drop (or copy/paste) into container fields. You could however write a routine using AppleScript to write the image to a file, convert it to JPEG or PNG,* FTP it, then Insert the converted file into the container. Kind of the long way around, but not all that hard to do.

*Unfortunately, as you noticed, you don't get any info on the container as to its original name & extension, so you'd just have to choose a default format for all.

Posted

How do I do your AppleScript test on my Mac so I can test Leopard before responding to this guy on the Mac forum? when I open AppleScript Utility I don't se how to actually create a new script or anything like that..??

Posted

I am not sure the OS X clipboard HAS a default format - or that is has a format at all. If I copy a .jpg image in a browser (using Copy Image) and paste it into a container - Filemaker then offers to export it as .pct. But if I paste the same image into Mail, it becomes a .tiff. Do the same with a .png source, and it's .png in Mail, but .pct again with Filemaker. The Finder's Show Clipboard command doesn't say anything about the format beyond "picture". So it seems that each target application decides for itself what "picture" means. All of the above refers to the clipboard - drag'n'drop may be the same, or it may be something else again.

In any case, what you see is what it is, and I don't think there's much you can do about it, other than export the image as .pct, then convert it to whatever you need - or abandon drag'n'drop altogether.

Posted

Yeah, that's the way it seems to be working out, which is just so frustrating. This works absolutely perfectly on Windows.

The whole problem here is that I have scripts in FM that export the image out of a container and FTP it to our web server. The script can also handle renaming, resizing, resampling, converting, etc. (all of this takes place within PHP code using the PHP SmartPill plugin).

The problem is the GD library for PHP (and any other scripting language or system in general) can't work with .pct files.

We have hundreds of items that we save pictures for off the web. I understand this is seemingly petty, but it really is tedius going through the process of saving the image to the disk and then inserting into the container each and every time.

What sucks even more about this is that when we take actual pictures of our product rather than just pulling a stock photo I have scripts which automatically pull them into FM off the digital camera...which of course is only available on Mac. So, I can't just tell them to use their Windows machines.

Posted

I am not sure the OS X clipboard HAS a default format - or that is has a format at all.

The pasteboard has no default format - it is up to the source to set the format of the data placed on the pasteboard. In addition, the source can, instead of placing data on the pasteboard, place a promise of data on the pasteboard to be delivered when the receiver requests it. The sender and receiver can negotiate the data type to be delivered.

When accessing the pasteboard using Carbon APIs, and when the pasteboard contains an image, the receiving application can access the image as PICT, regardless of the format that image is in on the pasteboard. The Quartz image framework can be called upon to make the translation from the original source format to the QuickDraw PICT destination format. The QuickDraw APIs were deprecated in Mac OS X 10.4 and remain deprecated (but not gone) in 10.5.

To the extent that there is a "default" format for the pasteboard it is that any application, FMP included, has the ability to request the data from the pasteboard in PDF format. I suspect they are using the deprecated Carbon APIs in their drag manager support and are relying on the associated QuickDraw routines rather than the corresponding Quartz routines. So while they have moved their core image handling routines over to Quartz with the advent of FMP 7, they probably missed the drag manager routines and these remain using QuickDraw calls.

Posted (edited)

So do you have any idea how to relay this information to FileMaker without them blowing me off? I've called their tech support with paid support codes and they won't acknowledge the problem is on their end. They keep blaming it on the OSX clipboard. I did go ahead and file a bug report as well and I included your information here, but I've never gotten any response from FM on that.

Edited by Guest
Posted

You should file a bug report. Tech support is useless for these types of behaviors.

I suspect, however, that this is very low on their priority list. All of the engineers I know at FMI are smart enough not to comment on the priority of fixing issues like this.

Posted

The problem is the GD library for PHP (and any other scripting language or system in general) can't work with .pct files.

I know virtually nothing about PHP, but on a Mac platform converting a .pct to virtually any other format is a rather trivial task. Surely you could find a way to do this - either immediately following insertion, or upon export.

This topic is 6236 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.