> operator/operand type mismatch. > > There are many others, but I have this documented here (with > pictures): http://www.medicaresoftware.net/ftp_www/exe_errors.rtf
What is the value for loptinfieldobject.csignatp in both environments? You could track this down to see why you're not getting an expected value in the EXE environment. You can also make the code much more bullet-proof by making sure lnentrynum is getting either the desired value or a useful default, such as: If Empty(lcEntry) lnentrynum = 1 Else lnentrynum = Ascan(This.acsignatp, lcEntry) Endif However, I have no love affair with having to perform (potentially a bunch of) validation tests on internal control values (not incoming data, but control values being passed as parameters or object properties between processes). I feel the correct way to make these situations bullet-proof is to insure that properties are initialized with useful defaults in the first place, and that any process that changes them does not screw them up. I'm elaborating because there was a recent discussion on validating passed parameters, which is akin to this situation. In both cases, it can result in redundant and unnecessary logic to go through all kinds of checks on these types of values every time they are accessed. Better to just set them correctly in the first place and then keep changes to them valid at the time they are changed. As this applies to this example, the acsignatp property wouldn't be set to logical .F. in the first place, and that would prevent this code from failing. Bill _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
