Premise Video demonstrates the use of object-oriented techniques.

[123]

The following video demonstrates how Premise's object-oriented architecture is used to good advantage. The video shows how inheritance and extension are used to enhance the capabilities of an existing Premise class.

Overview

• Premise contains an existing class called Pump. You can't (or shouldn't) alter its basic definition.
• We define a new custom class called PumpExt that has an extension relationship with Pump. In effect, PumpExt serves to extend the capabilities of the existing Pump class.
• LogMaster is a module that defines a new class called LogMaster. The LogMaster class defines the ability to log events to an MDB file.
• We let PumpExt have an inheritance relationship with the LogMaster class. In effect, PumpExt inherits all of LogMaster's capabilities.

Recap

• Pump is extended by PumpExt.
• PumpExt inherits from LogMaster.
• So Pump now has the capabilities of LogMaster.

The video continues to demonstrate how to add a script that is triggered whenever the Pump's PowerState changes. The script's code will log the changes to an MDB file.

If, at a later date, you enhance the LogMaster class, every class that inherits from it will be automatically enhanced. Neat.

 

[kmitchell]

123,

Thank you once again for sharing your knowledge and expertise. I've been working on the Temp05 module and I was using the original WeederTech module as an example. I saw your recent post about that module not being a proper Premise driver so I've now started over using your WeederTech module as an example to follow.

I've been having difficulty getting my Temp05 module to follow your WeederTech module and after viewing this video I think I can see why. I did not know about Expert Mode, which helps a lot when you're building a module from scratch and adding inherited classes. I have a list of questions but I'll hold off until I've done a bit more digging into the help files.

Thanks again,
Ken

 

[123]

... I've now started over using your WeederTech module as an example to follow.
...

Learning how to create drivers was a very long journey for me and I'd like to make that a shorter trip for others. Be sure to have a look at the School of Hard Knocks thread ... especially the part about not converting an existing driver into a new one!

All elements within a driver have a unique identifier (GUID). You can see this for yourself by simply editing an XDO file (I use Notepad++ and set the Language to XML). If you alter the WeederTech's source code to convert it into a Temp08 driver, it will retain the WeederTech's GUIDs. That's a very bad thing and I know this from experience! Importing the WeederTech and 'cloned' Temp08 drivers into Builder will cause them to fuse into an unholy mess because, under the hood, they share the same GUIDs. It's a train wreck and you stand to lose hours of work.

Here's what to do if you want to create a new driver (Temp08) based on an existing one (WeederTech):

1. Create a new Module for the new driver.
2. COPY the bits you want from the existing driver into the new one.

When you copy a Class or Property from one Module to another, Builder will give the copied item a unique GUID. I avoid copying PropertyChange scripts from one module to another because, if memory serves me well, they remain "attached" to the original module. Delete the original module and the copied PropertyChange scripts are trounced.

Another little gotcha is that after you create a fresh new Method or Function, and finish giving it a new name, you must click the Content area and enter at least one line of source code! Just a single comment quote is sufficient. If you don't, and click somewhere else, Builder deletes the new function. I guess the intention was to disallow the existence of empty functions.

 

[kmitchell]

Learning how to create drivers was a very long journey for me and I'd like to make that a shorter trip for others. Be sure to have a look at the School of Hard Knocks thread ... especially the part about not converting an existing driver into a new one!

Again, Many thanks for making this easier for us!

All elements within a driver have a unique identifier (GUID). You can see this for yourself by simply editing an XDO file (I use Notepad++ and set the Language to XML). If you alter the WeederTech's source code to convert it into a Temp08 driver, it will retain the WeederTech's GUIDs. That's a very bad thing and I know this from experience! Importing the WeederTech and 'cloned' Temp08 drivers into Builder will cause them to fuse into an unholy mess because, under the hood, they share the same GUIDs. It's a train wreck and you stand to lose hours of work.

Here's what to do if you want to create a new driver (Temp08) based on an existing one (WeederTech):

1. Create a new Module for the new driver.
2. COPY the bits you want from the existing driver into the new one.

When you copy a Class or Property from one Module to another, Builder will give the copied item a unique GUID. I avoid copying PropertyChange scripts from one module to another because, if memory serves me well, they remain "attached" to the original module. Delete the original module and the copied PropertyChange scripts are trounced.

I'm pretty familiar with GUIDs. It appears that there is a reference to the original GUID in the property change definition that doesn't get updated when you copy a PropertyChange script. I tried moving a PropertyChange script and that seemed to work correctly but I agree that the better way is just to create the scripts from scratch in the new module.

Another little gotcha is that after you create a fresh new Method or Function, and finish giving it a new name, you must click the Content area and enter at least one line of source code! Just a single comment quote is sufficient. If you don't, and click somewhere else, Builder deletes the new function. I guess the intention was to disallow the existence of empty functions.

That little "feature" is almost enough to make you lose your religion! I thought I was losing my mind the first couple times that happened. :angry2:

Thanks for the advice and guidance.
Ken

 

[123]

Premise Builder is a fairly solid application but it does exhibit the occasional quirk. If you use the code editor extensively it can lose its place ... the cursor cannot be moved, you can't scroll, and whatever you type seems to appear elsewhere. Just click somewhere in Explorer's treeview, to get out editing the function, and then click the function again ... everything will be back to norbal :angry2: Not destructive; just a nuisance.

 

[etc6849]

I've noticed this too. I think it usually happens when I set a break point in one script macro and let the pointer get to it, then click on another. The yellow arrow does not move when I click on a different script and this can be very confusing especially if you click the a different script by accident! I have to go back to the original script and remove the breakpoint then click "stopdebugging."

Premise Builder is a fairly solid application but it does exhibit the occasional quirk. If you use the code editor extensively it can lose its place ... the cursor cannot be moved, you can't scroll, and whatever you type seems to appear elsewhere. Just click somewhere in Explorer's treeview, to get out editing the function, and then click the function again ... everything will be back to norbal :rofl: Not destructive; just a nuisance.

 

[etc6849]

123, your statement below scares me! I have copied modules, then pasted and renamed them to create a new module before. Is this what you are saying not to do? I always assumed that when I copied and pasted within premise it was changing the GUID for me.

Or are you saying someone should never rename an exported xdo file, then import it (assuming the original xdo file is still loaded too)? This sounds like a bad idea and could crash Premise I would think.

Also, is there an easy way to add a custom device object under sys://Schema/Device/AudioVideo/Home/ ? I want to create a multiswitcher/receiver hybrid, but I don't think there is any object in under home that could bind to all of the features. I think I've learned enough to create the module, but we'll see about that when I have some free time.

"All elements within a driver have a unique identifier (GUID). You can see this for yourself by simply editing an XDO file (I use Notepad++ and set the Language to XML). If you alter the WeederTech's source code to convert it into a Temp08 driver, it will retain the WeederTech's GUIDs. That's a very bad thing and I know this from experience! Importing the WeederTech and 'cloned' Temp08 drivers into Builder will cause them to fuse into an unholy mess because, under the hood, they share the same GUIDs. It's a train wreck and you stand to lose hours of work.

Here's what to do if you want to create a new driver (Temp08) based on an existing one (WeederTech):

Create a new Module for the new driver.
COPY the bits you want from the existing driver into the new one.

When you copy a Class or Property from one Module to another, Builder will give the copied item a unique GUID. I avoid copying PropertyChange scripts from one module to another because, if memory serves me well, they remain "attached" to the original module. Delete the original module and the copied PropertyChange scripts are trounced."

 

[123]

... I set a break point in one script macro and let the pointer get to it, then click on another. The yellow arrow does not move when I click on a different script and this can be very confusing...

Ah yes, that's another annoying quirk. The solution is to avoid clicking away from the script with the breakpoint or to simply exit debugging mode (SHIFT+F5).

 

[123]

... I have copied modules, then pasted and renamed them to create a new module ...

Here's an example of what you should not do:

• Import the ELK M1 driver into Builder and rename it to DSC driver.
• Change the code, add new classes, etc in order to support DSC security panels.

This new DSC driver will have the same internal GUIDs as the ELK driver! If you now import the ELK M1 driver into Builder, it will fuse with the DSC driver and create a tangled mess.

Here's an example of what you should do:

• Import the ELK M1 driver into Builder.
• Create a new Module and name it DSC driver.
• COPY the parts you need from the ELK driver into the DSC driver.

If you copy/paste classes and properties within Builder, they will be automatically assigned new GUIDs.

 

[123]

.. is there an easy way to add a custom device object under sys://Schema/Device/AudioVideo/Home/ ? I want to create a multiswitcher/receiver hybrid...

To my knowledge, there's no easy way to do that. The Class Wizard helps you build all kinds of new Home objects for Lighting, Appliances, Security, etc but not for AudioVideo.

I'm not saying you can't create new AudioVideo Home objects ... just that it is not easy. Here's something to get you started:

1. Enter Expert Mode (select something in the Contents window and then press CTRL+SHIFT+A)
2. Create a new Module (MyAV) and a new Class (MyAVGear)
3. Make a new MediaZone in Home and add a Switcher and Receiver.
4. In the Switcher's Properties window, find the Type property. It will display "Switcher".
5. Hold down the CTRL key and double-click the Type property.
6. The Explorer window will now show the Switcher class's definition in Schema/Device/AudioVideo/Home
7. Select and copy everything listed in the Contents window (AV_Component, Switcher_Base, BindingSource, etc)
8. Select the new class you created (MyAVGear) and paste the items into the Contents window.
9. Your new class (MyAVGear) is now identical to a Switcher and will appear as an available Home object for AV gear.

You'll need to repeat some of these steps for the Receiver class ... and copy the items you need to the MyAVGear class. I don't know how well MyAVGear will work but it's a start in the right direction.

 

[etc6849]

I think this will work. I haven't done this type of thing for a home object, but I've done a similar thing to sys://Schema/Device/Record to remove its persistence property by copying the record class and placing it under the same module as a PVR driver. There was some other steps I had to do like make the class browsable etc, but I was surprised at how easy it was.

.. is there an easy way to add a custom device object under sys://Schema/Device/AudioVideo/Home/ ? I want to create a multiswitcher/receiver hybrid...

To my knowledge, there's no easy way to do that. The Class Wizard helps you build all kinds of new Home objects for Lighting, Appliances, Security, etc but not for AudioVideo.

I'm not saying you can't create new AudioVideo Home objects ... just that it is not easy. Here's something to get you started:

1. Enter Expert Mode (select something in the Contents window and then press CTRL+SHIFT+A)
2. Create a new Module (MyAV) and a new Class (MyAVGear)
3. Make a new MediaZone in Home and add a Switcher and Receiver.
4. In the Switcher's Properties window, find the Type property. It will display "Switcher".
5. Hold down the CTRL key and double-click the Type property.
6. The Explorer window will now show the Switcher class's definition in Schema/Device/AudioVideo/Home
7. Select and copy everything listed in the Contents window (AV_Component, Switcher_Base, BindingSource, etc)
8. Select the new class you created (MyAVGear) and paste the items into the Contents window.
9. Your new class (MyAVGear) is now identical to a Switcher and will appear as an available Home object for AV gear.

You'll need to repeat some of these steps for the Receiver class ... and copy the items you need to the MyAVGear class. I don't know how well MyAVGear will work but it's a start in the right direction.

 

[etc6849]

Thanks for the hotkeys for us non-programmers :rofl:

... I set a break point in one script macro and let the pointer get to it, then click on another. The yellow arrow does not move when I click on a different script and this can be very confusing...

Ah yes, that's another annoying quirk. The solution is to avoid clicking away from the script with the breakpoint or to simply exit debugging mode (SHIFT+F5).