Page 1 of 1

Dotnet plugin bridge: enhancement request.

Posted: Mon Nov 05, 2012 11:43 am
by bokkie

I'd like to ask for an enhancement to the Dotnet bridge if it's possible.

First, do the following: open any IA project and drag say, a MessageBox onto the MSIcode window. It pops up a dialog where you can enter the text, caption and so on. You can also select a variable that the result is to be returned to.

In my plugin, I open a Dotnet dialog of my own and I've put two combo boxes on it. One, is fixed and you can select from it but not edit it. The other combo box is blank and that's where my enhancement comes in. Going back to the MessageBox, IA is able to pass all user defined variables into it and you can select one of the items previously defined or you can enter your own variable name. That's more or less how it works on many of the statements anyway. In short, giving back to IA a selected variable.

When I drag my Dotnet plugin onto the MSIcode window, the bridge makes a call to a method called DesignTimeEdit. It takes four arguments: window, state, newState and dispayDialog. That's all okay. What would be nice is if DesignTimeEdit could be given a list of all the variables that IA knows about. If you look at the runtime side of the bridge, there's a method the bridge calls called RunTimeExecute. The second argument is a comma-separated string of all the variables (system and user defined and their values). I can enter my own variable name but it assumes I've already created it before I use my plugin.

That is, I'd like to be able to mimic the same usage as you find in many other statements and other plugin that allows a variable selection or edit.

If that information is made available to RunTimeExecute is it possible to give the same information to DesignTimeEdit as well? I suspect there might be a good reason why it can't but it's equally possible its use might have been overlooked.

Is this something that the team could look at? If it is possible to add it could it be done as soon as you can as I think the value of the bridge and Dotnet plugins would be considerably enhanced with it.

Francesco, you've been involved with the bridge to some extent so you might be able to see what I'm getting at.

Pawel, as the original author of the bridge is there anything you'd like to say about my enhancement?

Re: Dotnet plugin bridge: enhancement request.

Posted: Tue Nov 06, 2012 1:31 pm
by FrancescoT
Dear Bokkie,

I understand perfectly what you are refering but actually this possibility it is not available with the IA plugin SDK itself.
In fact, if you have a look at any InstallAware plugin, including those distributed by InstallAware directly, if a Variable is used it must be manually entered.

I have already discussed about this possible enhancement ... but honestly, I don't remember how it was concluded.

Let me verify if exist any possibility to have it in future.


Re: Dotnet plugin bridge: enhancement request.

Posted: Tue Nov 06, 2012 1:44 pm
by bokkie

My apologies if I've misunderstood what you wrote. Let me explain:

I created a variable using for example Set Variable MYVARIABLE

I then dropped a Convert Case statement on the MSIcode window. If I select the Variable drop down I can either enter another variable name or I can select MYVARIABLE. That is, IA can pass the variable names created before the Convert Case statement into the dialog that Convert Case displays. That's what I'd like to do in my plugin dialog as well.

The bridge does that when it calls the runtime method RunTimeExecute. The bridge doesn't or can't do it when it calls DesignTimeEdit in the IDE. But as I mentioned, Convert Case can do it. For sure, Convert Case is not a plugin itself but I was hoping the bridge could do something similar. It it can't that's fine. If changing the bridge assemblies could do it then it would be a nice enhancement.

I won't lose any sleep if it can't be done as you have confirmed it's not possible at this time.

Edit: Francesco, I understand what you mean with the plugins as you must enter the variable name. I was confusing plugins with statements but they're not the same. What I have done in my plugin is that if I select one of the fixed items in another drop down, I use that to pre-fill the variable name with a default name if nothing has been entered. If a variable name was entered, then selecting another item in the other drop down does not change the variable name. It can be edited afterwards. That's working okay: what does worry me is if the variable name's content can get back to the MSIcode window! :)

Re: Dotnet plugin bridge: enhancement request.

Posted: Wed Nov 07, 2012 1:50 am
by christ23

nice to hear from you! :)

The functionality you are asking for is the same i would like to have. Fine that you wrote it down here as a request!

Let's see what the team can do for us ...

Re: Dotnet plugin bridge: enhancement request.

Posted: Wed Nov 07, 2012 2:18 am
by bokkie

Good to hear from you as well. I was wondering where you were as the plugin Early Adopters Movement had gone very quiet. Have you hit any snafus with your development efforts? I'm making very good progress with mine but I hit a really nasty problem in VS2012. I created my IDE and runtime bridge assemblies with VS2012 and they were working fine until I added a Windows form. At that point I started getting resource file generator errors that completely taco'ed the build and that was that. I didn't know it was the form that did it as it had nothing more that a solitary button on it and how hard is that to break. :roll:

Anyway, I lost a day and a half tracking down the source of the error on the evil internet and there were more different answers than grains of sand on a beach. VS2012 completely lost the plot. I then recoded the whole solution to use VS2008 and I've no more problems. I didn't mind being an "early adopter" of VS2012 and I might have managed if I had used VS2010. It's fair to say that VS2008 has been round the block many times. Would I say VS2012 is no good for plugins? I'm not saying that specifically but I got so far down the road that when my form killed the compilation it was frustrating to go back to VS2008 what with installing it and so on. There are many good points about VS2010/2012. It wasn't the plugin source that killed it, rather VS2012 did it all by itself.

Right now, I'll stick with VS2008 for plugin usage as it's stable. Perhaps in a year's time when the service packs have stabilised I'll move on. Funny thing is, I never had problems with VS2012 at my previous job.

I'll nail my colours to the mast and recommend that VS2008 might be a better choice for now for plugin development. I'm sure some will get by with VS2012 just fine but there's an air of uncertainty about it that's well known. :(

Re: Dotnet plugin bridge: enhancement request.

Posted: Thu Nov 08, 2012 9:26 am
by christ23

hmmm i am also using VS1012 not yet. But, in VS2010 the plugin development is quite right, seems to be a VS2012 problem ...