SC companion: couldn't create component peer

[Stephen Hill]

This has been an elusive problem a client has been having that I could not reproduce until just recently. Under certain client conditions, eventually all 'SCDownload' (and upload at least, I have not tested enough else yet) will eventually result in nothing but "java.lang.InternalError: couldn't create component peer" and this cannot be fixed without quitting the filemaker application, and starting it fresh. This occurs on all databases opened, even with all closed and re-opened, the application must be exited.

I have been testing for this for months, without any success, until testing another error they have more frequently. After those tests, I finally received the component peer error, and I'm wondering if perhaps they're related. Below is the environmental detail.

Tested permutations

OS: Windows XP, Vista, 7

Java: 1.6.0_20, 1.6.0_23 [haven't tried 1.6.0_24 yet]

Filemaker: 11.0v2, 11.0v3, Adv 11.0v3

Supercontainer Companion Plugin: 2.75, 2.792 [2.75's are being updated, but they've been stuck and required manual clearing]

Supercontainer Server: 2.792

Failure hunting

Under all permutations of existing client situations plus a few of my own, I have attempted to force this error to occur. I've even processed multiple GB upload/download to try to force a problem, but could not get this result. The one extra factor reported most often was that this failure would occur typically after a period of idle. So I tested hard runs followed by idles of minutes, hours, days.

Finally, we were testing another client error ("The process cannot access the file because it is being used by another process") which was the result of attempting to download a file to the temporary directory that was already downloaded and currently open. After an overnight idle after testing this a few times, I finally received the component peer error ("couldn't create component peer").

Once the component peer error starts, the only way to clear it is to quit the filemaker app and start it fresh (something happening in the java side?) I'm not entirely sure what supercontainer companion plugin does, but is it possible that the extra downloaded files that cannot overwrite the opened one are somehow sticking around and eventually causing a problem?

I will continue to do testing to attempt to exactly be able to duplicate this error.

I run multiple plugins, but the client uses only Supercontainer Companion Plugin and Scribe (this problem occurred before Scribe was added to their machines.)

Attached log with partially sanitized urls

20110405 360Plugins_FMAdvanced process using and component error.zip

[Smef]

Let me know if you can find out what is causing this error to happen for you. One thing you may want to try in the mean time is using SCChooseFile to select the directory to download the file to rather than the showsavedialog flag. It may handle the download of the file a little differently and work around this issue.

EDIT: One thing I noticed which it seems that you did as well is that you receive and error when trying to download and open a file over another file which is already opened. You should not be trying to download over a file which you have open in another application. If you do not try to download and save over a file which is open in another application does the error go away?

[Stephen Hill]

EDIT: One thing I noticed which it seems that you did as well is that you receive and error when trying to download and open a file over another file which is already opened. You should not be trying to download over a file which you have open in another application. If you do not try to download and save over a file which is open in another application does the error go away?

This is exactly the problem, and yes, so far it appears that without this error, the nastier component peer followup error does not occur.

The problem is that, as far as I can tell, I have no way to check if the file is currently *open* (and cannot be used to save a new file to.) Is there a function for this?

What is occurring is a user activity. They're clicking the button which runs the script which downloads the file, and then sends the event for the file to open. Some of the users appear to become impatient with their machines, or through activity click into another application or back into filemaker before the application finishes opening their downloaded document, and they do not believe it has opened yet. In these cases, the user clicks the button *again*, resulting in another download of the file, which then results in the first error (open in another process) because it's already open. This could also occur if the user was manually choosing a location (rather than the temporary file location) via a different process, and attempted to overwrite something they currently have open.

This has primarily occurred on a tempfile download/open, as while SCDownload uses a filepath within the temporary location, it's the same result for any successive attempt on that same stored file. If the file wasn't open, this wouldn't be a problem, but as listed above, my experience with automatically opening files for users is that some of them just plain don't notice and proceed to just keep clicking.

Although much of this is a training issue (and in fact, I'm moving past it in the tempsave&open solution by making a uniquely-stamped temporary save location on my own) it's still entirely possible in a manual download (letting the user choose a location, regardless of auto-opening.) Thus this is still a problem.

[Smef]

Unfortunately, there is nothing that we can do about this. This is a limitation of computers in general. You cannot save over a file which is in use by another application. This is something common to all computer software and operating systems and not something we can change.

Getting this error shouldn't affect the user's experience, though, since it will only happen after the file is already downloaded and opened. I recommend not showing the error to them, since it doesn't really affect them at all. You know the error is caused by trying to save over a file which is in use (which is what your script is doing), and you also know that it's not a cause for concern, so you can ignore the errors if you are looking through their logs at some point in the future.

If you want to avoid the error completely you will either need to change your script so that you don't try to save over the file each time (which you're doing) or tell your users not to try and re-download the file when it's already open. I would recommend telling the users to not click the button multiple times and not showing them an error if they do. You don't really want to be sending them the same file over and over, and if you re-download and re-open it under a different name each time they click it it will open multiple copies of the file, which you don't really want either. The simplest solution seems to be to not show the error to the user.

[Stephen Hill]

Unfortunately, there is nothing that we can do about this. This is a limitation of computers in general. You cannot save over a file which is in use by another application. This is something common to all computer software and operating systems and not something we can change.

I'm not asking for you to do anything about this portion off the problem, unless you have a method for checking if a file is open within one of the 360works products. This is the 'minor' error that may be producing a condition that results in the 'major' followup error which results in supercontainer companion plugin ceasing to work at all in uploads and downloads. I posted here to see if 360works had any information regarding the 'couldn't create component peer' portion, and noted that I've only seen it show up so far after the 'already open' error has occurred.

I can not eliminate all potential occurrences of the 'already open' as when providing a save as option, the user chooses where to put it and they may mistakenly attempt to over-write a currently open file. So I'm following up here.

[Smef]

Ah, so downloads of other, non-open files fail as well? I thought it was just affecting the one you already had open. If this is the case, can you post or email your log after you get these errors? You can email it directly to me or to [email protected].

[Frank 010]

Goodday,

New to SC, tried searching, but can't find this one.

I'm getting the same error ( java.lang.InternalError: couldn't create component peer) when doing a SCSetContainer in a script.

If I manually copy and paste the image, it works fine.

Any help / direction would be great!

Thanks,

Frank.