The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
|
|
Calling one form from another using DoInvoke
Posted: 24 May 06 9:57 AM
|
paroxetine effet paroxetine effet fiogf49gjkf0d I have a form called EventDoc_Attachments within the Eventix family. this is a data form
Sub ManageAttachments(Sender)
Application.BasicFunctions.DoInvoke "Form", "Eventix:EventDoc_Attachments"
End Sub
I am running this script in Debug mode using the "stop" command. In the Microsoft Script Debugger, I can see where execution hits the DoInvoke call, but continues on, apparently without executing the call. I made the change, saved and released the current calling plugin to "Everyone" so I know it should see it. I also put a "stop" in the AXFormOpen sub of the new form so I could get a indication that it was being invoked. The execution is not reaching this stop so that tells me that the form is not being invoked at all. The new form has been saved and released to "Everyone" as well.
I'm not sure where to look next at this point. Does anyone have any suggestions?
Thanks in advance,
Chris |
|
|
| |
|
Re: Calling one form from another using DoInvoke
Posted: 25 May 06 1:18 PM
|
fiogf49gjkf0d Ryan is correct regarding Data Forms. You want to use ShowViewForRecord because it returns a modalresult.
DoInvoke is a function so it may behave differently if you set a variable to catch the return.
I do something like this for my manage form calls:
stringResult = ...DoInvoke(Call)
stringResult = ...InvokeResult
(Do processing based on stringResult = "mrOk")
On the manage form I set buttonOKClick to this:
Form.ModalResult = mrOk
...InvokeSetResult = "mrOk"
I don't do anything with the Cancel button because I don't really care if it was cancelled. I believe the main difference of a manage form vs data form is the fact that no modalresult is set. ModalResult lets me use the FormValidate and other events so I don't have to think too differently when using one type of form over another. I have stock startup and tear down code that I can just paste into any form I wish now and have it behave the same in either scenario without any extra tweaking. |
|
|
|
Re: Calling one form from another using DoInvoke
Posted: 25 May 06 3:16 PM
|
fiogf49gjkf0d Originally posted by Jeremy Brayton
I believe the main difference of a manage form vs data form is the fact that no modalresult is set. |
|
Well, a little more than that. A data form has context, that is it *has* to be in context of a particular record. A data form is basically invalid unless it has a record for it's context. That's the biggest difference. And that is why you cannot use DoInvoke to launch a data form, because there is no way to give it context. ShowViewForRecord allows you to do that by passing in the basetable and recordid for the form's context. If you attempt to show a data form using DoInvoke nothing will happen. You won't see a form load or anything (I can't remember if you get an error or not or if it is just silent - but I think it is the latter) |
|
|
|
Re: Calling one form from another using DoInvoke
Posted: 25 May 06 6:11 PM
|
fiogf49gjkf0d Kind of how ShowViewForRecord passed with the table but no recordid just brings up an empty Form and doesn't save the underlying data no matter what you do to it? A Data Form is a manage form sprinkled with data binding code and some other fluff. It's more complex than that but I think in classes where manage forms are the base class and data forms are derived from it. You can turn a manage form into a data form (with a LOT of work) but you can rarely go backwards at least in the true sense. ShowViewForRecord without a recordid makes quite a nice manage form but I don't believe you can use it with a table and a manage form as the viewname.
I shouldn't have said main difference, as there are about 4 major ones with a slew of minor quirks: DoInvoke vs ShowViewForRecord, no ModalResult, no automatic data binding, and no record context (kind of falls under data binding). In a perfect world code on your manage form should be able to be copied to a data form and just work. OnFormValidate set to false wouldn't stop a manage form from closing in 6.1 but I believe the modalresult trick is what finally did it. The point is you shouldn't have to THINK differently when dealing with either type of form but because you do, it means you have to TEST differently. As if we need the extra work. |
|
|
|
Re: Calling one form from another using DoInvoke
Posted: 25 May 06 6:18 PM
|
fiogf49gjkf0d Loading a data form with ShowViewForRecord with a blank recordid brings up the form in "add" mode. It is blank, and supposed to save a new record to the base table upon save.
But yeah, a manage form is just a form with no data binding, no context A side effect of that is that some things don't work right - or at least not how you would expect them to. Things like the modalresult, validation events, etc. Sucks. Anyway, always fun to deal with those  |
|
|
|
Re: Calling one form from another using DoInvoke
Posted: 18 Mar 08 1:01 PM
|
I've run across another issue using ShowViewForRecord.
I have a data form that did work using this method. But in the process of later modifications, somehow I managed to break it so that now it sees the CurrentID but does not (apparently) retrieve the data. I find that in DEBUG mode, none of the bound controls are seeing the data. I have had this happen in the past and found that an inner join in one of the controls affected the (selection criteria? behind the) form. Changing the inner join to a left outer join resolved that problem.
This time, I am not able to determine what the problem is. The previous issue occurred with the same form so I am certain that it is not the exact same issue. I've tried using SLXProfiler but it only confirms (at least to me) that the record is not being retrieved; the displayed SQL shows that the form field controls are not being set to their corresponding values.
Is there a way to show what is happening at the point of data retrieval? Or am I (as I am beginning to believe, with a sinking feeling) going to have to completely rebuild this form from scratch? Incidentally, I have already copied the fields onto a new data form (from the original one) in hopes of resolving the issue.
Any insights would be, of course greatly appreciated. 
Thanks in advance,
Chris |
|
|
|