Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations John Tel on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Invalid or Corrupted OLE Object 1
- Thread starter ivancs
- Start date
-
1
- #2
Ivancs,
I have recently had many battles with this. I seem to have mitigated the issue somewhat with the following steps:
1) My OLE problems were with .BMP files saved into General fields. First, the best thing you can do is make them as small as possible. Do this by using something like Photoshop (what I recommened), and reduce the physical immage to no bigger than as big as you will actually use the image. In other words, sometimes the image you are storing is only used as a 2" x 2" images, for example, but if you check it's physical size, it's 6" x 6". Use Photoshop to resize the image to the size you want it, before storing it into the General field.
2) I have found that navigating too quickly through .DBF's with general fields, when the field is also a display item, causes an erroneous OLE error, but then the error itself actually corrupts the image. Amzaingly enough, simply ignorning the error causes the error NOT to occur. I know this sounds crazy but I implemented this in my own ON ERROR routine recently, and I have had NO OLE corruptions since then! (And I work extensively with OLE fields in 2.6). The way to do this is, in whatever your ON ERROR routine is (and if you don't have one, simply create it in or procedure file that is set with the SET PROCEDURE TO command). Then, add something along these lines:
If you don't already have an error capture routine,
In your main program add:
ON ERROR DO PRO2EROR WITH ERROR(), MESSAGE(), MESSAGE(1), SYS(16), LINENO(), SYS(102),;
SYS(100), SYS(101), LASTKEY(), ALIAS(), SYS(18), SYS(5), SYS(12), SYS(6), SYS(2003),;
WONTOP(), SYS(2011), SYS(2018)
then in your PROCEDURE FILE as mentioned above, add the following:
PROCEDURE PRO2EROR
PARAMETERS M.XERROR, M.XMSG, M.XCODE, M.XMODULE, M.XLINENO, M.XPRINTER,;
M.XCONSOLE, M.XDEVICE, M.XLASTKEY, M.XCURDBF, M.XGETFIELD, M.XDFLTDRIVE,;
M.XRUNMEM, M.XPRNDEVICE, M.XCURDIR, M.XTOPWIN, M.XLOCKED, M.XMISSING
SET CONSOLE ON
SET PRINTER OFF
SET DEVICE TO SCREEN
*
CLEAR TYPEAHEAD
*
IF M.EXERROR = 1420
RETURN
ENDIF
This will effectively cause FoxPro to complely ignore that the 1420 error was triggered, and keep going. You will never see an error generate, and your OLE object will appear normal. If you check the general fields later, just by viewing the table, you will find no corruptions in your OLE objects. I know it sounds absolutly crazy, but all of the testing I have done has shown this to be effective. (Even in my reasons are wrong... that's just my theory as to WHY it works.)
Please let me know if this helps,
-Scott
I have recently had many battles with this. I seem to have mitigated the issue somewhat with the following steps:
1) My OLE problems were with .BMP files saved into General fields. First, the best thing you can do is make them as small as possible. Do this by using something like Photoshop (what I recommened), and reduce the physical immage to no bigger than as big as you will actually use the image. In other words, sometimes the image you are storing is only used as a 2" x 2" images, for example, but if you check it's physical size, it's 6" x 6". Use Photoshop to resize the image to the size you want it, before storing it into the General field.
2) I have found that navigating too quickly through .DBF's with general fields, when the field is also a display item, causes an erroneous OLE error, but then the error itself actually corrupts the image. Amzaingly enough, simply ignorning the error causes the error NOT to occur. I know this sounds crazy but I implemented this in my own ON ERROR routine recently, and I have had NO OLE corruptions since then! (And I work extensively with OLE fields in 2.6). The way to do this is, in whatever your ON ERROR routine is (and if you don't have one, simply create it in or procedure file that is set with the SET PROCEDURE TO command). Then, add something along these lines:
If you don't already have an error capture routine,
In your main program add:
ON ERROR DO PRO2EROR WITH ERROR(), MESSAGE(), MESSAGE(1), SYS(16), LINENO(), SYS(102),;
SYS(100), SYS(101), LASTKEY(), ALIAS(), SYS(18), SYS(5), SYS(12), SYS(6), SYS(2003),;
WONTOP(), SYS(2011), SYS(2018)
then in your PROCEDURE FILE as mentioned above, add the following:
PROCEDURE PRO2EROR
PARAMETERS M.XERROR, M.XMSG, M.XCODE, M.XMODULE, M.XLINENO, M.XPRINTER,;
M.XCONSOLE, M.XDEVICE, M.XLASTKEY, M.XCURDBF, M.XGETFIELD, M.XDFLTDRIVE,;
M.XRUNMEM, M.XPRNDEVICE, M.XCURDIR, M.XTOPWIN, M.XLOCKED, M.XMISSING
SET CONSOLE ON
SET PRINTER OFF
SET DEVICE TO SCREEN
*
CLEAR TYPEAHEAD
*
IF M.EXERROR = 1420
RETURN
ENDIF
This will effectively cause FoxPro to complely ignore that the 1420 error was triggered, and keep going. You will never see an error generate, and your OLE object will appear normal. If you check the general fields later, just by viewing the table, you will find no corruptions in your OLE objects. I know it sounds absolutly crazy, but all of the testing I have done has shown this to be effective. (Even in my reasons are wrong... that's just my theory as to WHY it works.)
Please let me know if this helps,
-Scott
- Thread starter
- #3
Ivancs,
I'm not sure what you are requesting. ON ERROR is a fox command. The Code that I provided for PRO2EROR is a stripped down version of an error handler routine that I use, but has everything you need for OLE corruption. You should set the ON ERROR DO PRO2EROR early on in your main program, after you have set whatever environment variables you are going to use.
If you still need this code, let me know, and I will e-mail it to you, rather than post it up here.
-Scott
I'm not sure what you are requesting. ON ERROR is a fox command. The Code that I provided for PRO2EROR is a stripped down version of an error handler routine that I use, but has everything you need for OLE corruption. You should set the ON ERROR DO PRO2EROR early on in your main program, after you have set whatever environment variables you are going to use.
If you still need this code, let me know, and I will e-mail it to you, rather than post it up here.
-Scott
- Status
Similar threads
