Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Error 1736 on new editbox
Message
From
17/03/2016 08:42:52
 
General information
Forum:
Visual FoxPro
Category:
Forms & Form designer
Environment versions
Visual FoxPro:
VFP 9 SP2
OS:
Windows 10
Database:
Visual FoxPro
Application:
Desktop
Miscellaneous
Thread ID:
01633174
Message ID:
01633255
Views:
45
>>>>>>Running into something weird. In an inherited application, I just changed a table to have a single memo field instead of two char fields for notes, and replaced the pair of textboxes on the relevant forms with an editbox. There are two forms involved. The first is pretty much display-only, shows a grid of all records on one page and detail of the currently selected record on a second. A button on that form instantiates a form class for editing the record.
>>>>>>
>>>>>>When I test here, all works as expected. Both forms open and show the right data. At the client site, the display form is fine, but instantiation of the editing form class fails with error 1736 and the message says "Error instantiating the object EDTNOTES." That's, of course, the newly added editbox that replaced the two character fields.
>>>>>>
>>>>>>I gave the client a separate EXE to make the database change and he ran it before testing the updated application. The fact that the first form opens correctly and shows the data correctly means the table was properly updated.
>>>>>>
>>>>>>I had the client send me the updated table and tested with it here and both forms work as expected.
>>>>>>
>>>>>>The only differences I can think of are:
>>>>>>
>>>>>>- the client is using Windows 10, while I'm on Windows 7 (but that he could send me the modified table means we're not dealing with virtualization);
>>>>>>
>>>>>>- the client has the data living on a mapped drive on a server, while I'm testing locally. Given that things are working generally, I don't see how this could matter.
>>>>>>
>>>>>>I'm at a loss. Any ideas?
>>>>>>
>>>>>>Tamar
>>>>>
>>>>>What are all non-default properties for this editbox?
>>>>>
>>>>>Also, where do you open the table?
>>>>
>>>>ControlSource = ProdList.mNotes
>>>>DisabledForeColor = 0,0,0
>>>>FontBold = .T.
>>>>Height = 75
>>>>Left = 84
>>>>Name = edtNotes
>>>>TabIndex = 11
>>>>Top = 225
>>>>Width = 428
>>>>
>>>>No method code for this object. The form (class) is modal and "inherits" the table from the calling form (the display-only one), which opens it in the DE.
>>>>
>>>>Tamar
>>>
>>>Does the same form work correctly if you remove that editbox?
>>
>>It works here with the editbox. Don't know about on the client site without.
>>
>>>
>>>Is it using a class?
>>
>>First-level subclass, with nothing changed except size.
>>
>>
>>>
>>>Do you show the editBox content in the Display form?
>>
>>Yep, based on the same class, bound to the same field. That's why this is so baffling.
>>
>>>
>>>Are you able to ask the client to test intermediate builds for you (e.g. form without editBox or adding more logging, etc.)?
>>
>>Unfortunately, the way the app was designed, there's no easy way to configure one machine to run a different build than any other in the network. So, any testing like this that I want to do is going to require having all the users get out of the application. (As I said up front, I inherited this application.)
>>
>>Tamar
>
>Just the last point - say, you compile the app under different name without the editbox and with more logging and ask the client to test it.

I'd have to muck around with access to the data as well. It uses a configuration file to point to the data, but that's also in the shared data folder. (I helped him roll back to the previous version of both data and code yesterday so they could work.) But that may be the way to go. Going to check a few things with him today and then try to come up with a strategy.

Tamar
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform