Team,
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?
Dotnet plugin bridge: enhancement request.
Dotnet plugin bridge: enhancement request.
Peter. Smartly dressed, he still resembles an unmade bed.
InstallAware MVP
InstallAware MVP
-
- Site Admin
- Posts: 5361
- Joined: Sun Aug 22, 2010 4:28 am
Re: Dotnet plugin bridge: enhancement request.
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.
Regards
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.
Regards
Francesco Toscano
InstallAware Software
White Papers (HowTos) - http://www.installaware.com/publication ... papers.htm
Publications - http://www.installaware.com/publications-review.htm
InstallAware Help -F1 anywhere in the InstallAware IDE
InstallAware Software
White Papers (HowTos) - http://www.installaware.com/publication ... papers.htm
Publications - http://www.installaware.com/publications-review.htm
InstallAware Help -F1 anywhere in the InstallAware IDE
Re: Dotnet plugin bridge: enhancement request.
Francesco,
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!
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!
Peter. Smartly dressed, he still resembles an unmade bed.
InstallAware MVP
InstallAware MVP
Re: Dotnet plugin bridge: enhancement request.
Bokkie,
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 ...
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.
christ23,
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.
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.
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.
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.
Peter. Smartly dressed, he still resembles an unmade bed.
InstallAware MVP
InstallAware MVP
Re: Dotnet plugin bridge: enhancement request.
Bokkie,
hmmm i am also using VS1012 not yet. But, in VS2010 the plugin development is quite right, seems to be a VS2012 problem ...
hmmm i am also using VS1012 not yet. But, in VS2010 the plugin development is quite right, seems to be a VS2012 problem ...
Return to “Plug-In Development”
Who is online
Users browsing this forum: No registered users and 3 guests