Hi,
I'm totally new to Navision, so I might just make a dumb mistake here. ](*,)
I am developing a Control Add-In for use with the RTC to display a tree control (we have a tree control for the classic client, but since that uses a COM object, I cannot reuse this for the RTC, I think).
I build the C# add, registered it as Client Add-In, attached it to a field on a page and it is displayed correctly. I can also send events from my Control to the OnControlAddIn trigger. So far so good.
Now I want to get data from my RTC to the Control (otherwise I have an empty tree control which is a pretty boring thing). I read in the documentation that binding a global variable or function call to the SourceExpr property of the field is the way to do this. (I find this pretty limited, by the way, compared to the possibilities I had when integrating a COM object, but never mind).
So for test reasons I just bound a global string variable to my tree control and display the content of the string as text for my first tree node (doesn't make much sense, of course, but I just wanted to test the communication between my control and the RTC in a first step). I initialize the string with a global string constant.
I would now expect that string to be passed to my control via the set Value method. And it is, but only after get Value has been called first. So what happens is, my control is asked for the current value (which it can't know), the string is changed to that value and that value (which came from my control in the first place) is then set again. And when I change the value of the string again in the Navision code (I do that in the OnControlAddIn trigger for example, so that I know when it happens while testing), the same thing happens again. Instead of just setting the new value, Navision first asks my control and changes the string to whatever return value I give (if I return null, the RTC crashes, I guess with an uncaught exception). I don't see a way to get data from my RTC to my ControlAddIn. That can't be right, can it? What am I missing?
Any help appreciated,
Jutta
0
Comments
based on your description I guess you implement the IValueControlAddInDefinition interface. When using that do not forget set the value of the HasValueChanged member. If you default it to 'false' then RTC doesnt try to ask your AddIn for a new changed value. Though the big example of http://msdn.microsoft.com/en-us/library/dd983826.aspx contains setting that property but in the text based part it is not described deep enough.
I will contact the author of the documentation to see if we can improve it a bit.
Gabor Pesti
“This posting is provided "AS IS" with no warranties, and confers no rights.”
Software Developer Engineer in Test
MSFT
Dynamics NAV
Yes, sorry, I forgot to mention. My class for the Control AddIn is derived from WinFormsControlAddInBase and implements IObjectControlAddInDefinition.
And I do handle the HasValueChanged property like so at the moment:
So it should always be false. Still the RTC always calles Value.get before it calls Value.set. Did I do something wrong in implementing the HasValueChanged member?
Jutta
However I tried it meanwhile and seems actually working fine.
Did I get it right that you used debugger to show that get is actually called?
One additional possible thing pops into my mind (Assuming you only observed the effect and not verified invocation of get from debugger). Is the global variable you use as source expression actualy added to the dataset (form global variables click properties and there is an IncludeInDataset property...)? If that is missing that might cause that the value of the variable is not forwarded between the client and the backend.
Could you provide a sample code (both C/AL side and the C# AddIn) that you think should work but doesnt in practice?
Gabor Pesti
“This posting is provided "AS IS" with no warranties, and confers no rights.”
Software Developer Engineer in Test
MSFT
Dynamics NAV
no, I did not use the debugger, but I changed the text in my tree control whenever HasValueChanged.get, Value.get or Value.set are called, so I can see in which order they are called. In my original class, Value.get was called (no call to get HasValueChanged was done before that) on initialisation, followed by a call to Value.set. That behaviour did not depend on the variable I attached to the control in the RTC. Even if I did not attach a SourceExpr at all, the calls were the same.
The idea with the IncludeInDataset property was a good idea, it was not set, but unfortunately, setting the IncludeInDataset property to YES does not solve the problem.
I had a little example control from the MSDN. Their control class "MyFieldPopupAddin" works like a breeze and gladly accepts all data I throw at it, so I looked at that in more detail. They use the StringControlAddInBase instead of the WinFormsAddInBase which already has the event and control interfaces implemented. So I changed my control to inherit from that and to override the Value.get and Value.set methods. Still did not work.
I now found an ugly but working solution by leaving the Value.get and Value.set methods alone and reacting to a OnTextChanged event for my control instead and let the base class do the data exchange. And for some magical reason, that works. I can now pass a string from the RTC to my Add-In. It's quite a hack, though, since the Text member of my TreeControl (which is where the string ends up) doesn't really have anything to do with it. I am just misusing it for that at the moment, because that's were the base class puts the data (which makes perfect sense for a real String control like a textbox, I guess).
Jutta
Just came across your post, not sure if you ever figured this out in a better way, but here is what I do.
If you add a property to your class called "public object Value" it should work the same as the Value get; set; on the StringControlAddInBase.
Example:
public object Value
{
get
{
return null;
}
set
{
if (value is string)
{
string data = (string)value;
if (data != string.Empty)
{
if (data.Length > 0)
((YourUserControl)this.Control).SomeProperty = data;
}
}
}
}