How to revert a change made by a plugin during uninstall

[Weatherlights]

Hi

I started developing some smaller plugins (one for eventlogs and one for certificates). I finally figured out how this stuff works out but I wounder how the uninstallation works. Do I need to develop a second plugin that remove changes made by the first plugin or can I somehow implement a method in the first plugin that can be used during the uninstallation?

Like: I want to create an event log source during installation and I want to remove it when the user decides to uninstall the software. Could I do that with a single plugin?

Best regards
Hauke

[bokkie]

Of course!

The plugin must contain all the methods and the correct parameters because it uses the same bridge assemblies and the plugin contains appropriate methods for use during design time in the IDE; when you build the installation media and install it and uninstall it. I don't know about plugin development using C++ or Delphi. I only know how to do them using DotNet and C#.

[Weatherlights]

Hey bookie

thank you for your reply. Do I need two functions in the MSICode to achive that? One to create the eventlog source during install and another (different) one during uninstallation? Or can I achive that by a single line of code in the MSICode interface?

Thank you in advance.
Hauke

[bokkie]

When you drag-and-drop the plugin to the MSIcode you usually display a form. The form is where you'd enter the name of the variable to return some value back to the MSIcode. In addition, the form is where you'd have pulldowns for selecting what you want the plugin to do for that call at that time when you install or uninstall. When you close the form you usually close the plugin. For example during installation you'd run your plugin in the MSIcode somewhere where you know it will be run during installation. That means you might have a statement that looks like:

DoSomethingHere (installation) return result in XYZ

That is, you might select installation from a pull down because that's what you'd like to do and you'd enter variable XYZ in a textbox, something on those lines. You'd then drag-and-drop the same pluging somewhere in the uninstallation area of MSIcode. You'd likely select uninstallation from the pulldown and perhaps enter variable FRED in the textbox to give you something like this:

DoSomethingHere (uninstallation) return result in FRED

So, it's all done with the same plugin. During installation, the MSIcode will do whatever else needs doing. Then when it encounters the statement DoSomethingHere (installation) return result in XYZ your plugin is called and will be given the statement. Your plugin would break it down into it's components and all you have to do is check whether the "action" is installation or uninstallation and do whatever is required for what you're trying to do. The parameters passed into the plugin by the bridge is how you work out what needs to be done which is why your plugin is called at different times with different parameters. That's also why I believe plugins written in C++ and Delphi are different to those written using DotNet and C# for example.

If you want a plugin for installing and another plugin for uninstalling that's also perfecty legal but there is an advantage by keeping the code for both types in the same plugin but you don't have to. Ultimately the bridge knows what plugin to call because you specify the names of the assemblies your plugin requires as well as defining the namespace and class name the plugin needs to use in your plugin when it's invoked.

I have a freeware plugin I could give you that shows what you need to do. Unfortunately, it's currently broken but if you'd like to have it, it'd give me the incentive to get it working again.

[Weatherlights]

Hey bokkie

thank you for the answer. It helped a lot. I implemented some stuff... getting variables during the installation... however the only thing I try to figure out is how I can declare a field to pass results back into a variable.

Could you help me out with this last one?

Best regards
Hauke

[bokkie]

Hauke,

My apologies if I misunderstand your question. Unlike IA's plugins the bridge cannot help you to discover their names when your plugin is called. That is, IA's plugins let you open a pulldown and, automagically, you can see all the variables that have been defined in the MSIcode. The bridge plugins don't have access to that. Instead, you'd need to create a variable first, let's call it XYZ, and then when your plugin runs in the IDE, you'd open a form and enter the variable name in a text box. You could populate the textbox or an editable pulldown with a list of hard-coded names so your IDE user (you?) could select one from a list. Whichever approach you use you'd still need to create a variable using the Set Variable statement but your plugin can't discover the names. So, if we have a statement like earlier:

DoSomethingHere (installation) return result in XYZ

You'd have to enter XYZ in a textbox or have a default name "known" in advance and add a Set Variable XYZ somewhere prior to the plugin's call. Coming back to what I think you're asking, how do you pass a result back to XYZ?

When your plugin is called during runtime, the bridge passes a comma-separated list of variable name and values. It looks something like this:

ABC,-2,FRED,Hello,XYZ,,DATE,"22nd August", and so on. Split the list by comma to get the name-value pairs. If any variable (look at DATE) contains spaces, you should/must put the values in double quotes. The name/value pairs look a bit like CSV lines you're probably more familiar with Excel-like files. Your plugin must handle missing variable names. For example, let's say you define variable XYZ in the plugin but don't create it. The name won't appear in the list of name/value pairs and you can't simply think to yourself let's add XYZ and its value at the end of the comma-separated list you return. I seem to recall it use to raise a runtime exception-cum-crash in the IDE. Don't quote me on that!

Finally, if you want to replace the value of DATE with something else make sure you guarantee the integrity of the concatenated string you return. It's not just double-quotes you have to worry about. Enter commas anywhere in the value and you are asking for major league trouble.I know this from experience. It hurts; and the bridge doesn't like it either as it has to martial the names and values to and from IA. Whatever value your plugin returns just avoid commas and double quotes in the value as if they contained bubonic plague.

In short, your plugin can process the list to get a value and do something with it. It can also substitute the existing value with a new value if you need to pass something back. Your plugin can read or write the value for a variable but you need to handle the list with care. Like I say, bridge plugins cannot discover the variable names defined in the IDE.

I'm not sure if that helps or not.

[Weatherlights]

Thank you a lot... Specially the hint about the Quotations were helpfull. I managed to develop a robust solution to handle those now. My module is now fully functional... Will post it quiet soon.