Advanced programming

collapse

#
- 1.) Application.config
- 2.) Basic concepts
  - 1.) Composite pattern
    - 1.) Lifecycle
    - 2.) Programming
  - 2.) Properties
    - 1.) Local
    - 2.) Network
    - 3.) Persistance
    - 4.) Configuration
    - 5.) Logging
  - 3.) Synchronous Methods
    - 1.) Virtual methods
  - 4.) References
    - 1.) 1 Object
    - 2.) N Objects locally
    - 3.) N Objects Network
  - 5.) Events
  - 6.) Asynchronous methods
  - 7.) Configuration
    - 1.) Config storage
    - 2.) Overriding
  - 8.) Messages and Alarms
    - 1.) Alarms
  - 9.) Database
    - 1.) Usage
    - 2.) Extend
      - 1.) EF 4.0
      - 2.) EF 7.0
    - 3.) Persistable queries
  - 10.) Designs
    - 1.) GUI Design
      - 1.) Set and convert Properties
      - 2.) Styles and Setter
      - 3.) Property trigger
      - 4.) Datatrigger
      - 5.) Events & trigger
      - 6.) Animations
      - 7.) Resources
    - 2.) Reports
      - 1.) Programming
  - 11.) Diagnose and Debugging
  - 12.) Updates
- 3.) UI-Controls
  - 1.) UI-Library integration
  - 2.) iPlus-Controls
  - 3.) Custom Controls
- 4.) Application programming
  - 1.) Multithreading
  - 2.) Businessobjects
    - 1.) Navigationless
    - 2.) Navigable
    - 3.) Context dependant dialogs
    - 4.) Background Tasks
  - 3.) Manager classes
  - 4.) Process applications
  - 5.) Workflow classes
  - 6.) External systems
    - 1.) Mobile devices
    - 2.) OPC UA Communication
      - 1.) Server
    - 3.) Simatic S7
  - 7.) Bit masking
- 5.) []

;

Introduction

In the previous chapters, you learned how to develop classes based on the iPlus framework, create your own assemblies and database models and design the user interface. However, these changes were only carried out on the own development database - just how are these changes rolled out to customers or made available to other developers?

Roll out and register assemblies (step 2)

In the Composition section you have learned how new classes are registered for the iPlus runtime . In your case, this means when your new or changed assembly is shipped or deployed, only the latest hard-coded functionality is available.

Update database model (step 1)

Before doing so, your database model or the iPlus database model must be brought up to date . Therefore, the SQL scripts from the DBScripts directory are executed (login with the Ctrl key) first.

Transfer database changes (step 3)

Designs , Texts, messages , Methods (scripts) , Application trees and application definitions , Configurations , Application data are stored in the database. The majority of your work is therefore in the SQL database and less hard-coded in the assemblies. Without this data, your project will not be able to run at all. The changes from your development database must therefore also be transferred to other target systems. Either made available to other developers or transported to a production system at your customer's.

Large systems such as SAP speak of a so-called "Change-Request -Management"and Transport Requests.

A similar transport mechanism offers you iplus:

Export / Import

The transfer of database changes can take place in two different ways :

Active: Data is transferred from one database to another database by the user himself. The transfer can either take place directly via two database connections or indirectly via writing and then reading XML files (shared folder principle).
Passive: The data are exported as ZIP archives and integrated into the Visual Studio project of the corresponding assemblies. When the assemblies are rolled out on the target system, these ZIP archives are automatically extracted during the registration process and imported into the target database.

First read the following chapter on how you can actively transfer the changes and create ZIP archives for the passive variant:

Include ZIP-Archive to Visual-Studio-Project (passive)

Place ZIP archives, that you created with the export program, in the "VBControlScripts"-subfolder of your Visual Studio project. (This folder may only be named like this!):

Add the ZIP archive in the project tree.
In the properties window, set the "Copy to output directory" setting to "Copy always".

During the compilation process, the ZIP archives from all assemblies are stored (copied) together in the target directory "bin\Release\VBControlScripts". Do not forget to copy the VBControlScripts directory when you deploy it on the target system!

Important NOTE:

Your ZIP archives should only contain the data that fits to the corresponding assembly and the classes. Therefore, do not create archives containing, for example, designs belonging to classes from other assemblies!

Roll out and register assemblies (step 2)

Update database model (step 1)

Transfer database changes (step 3)

Important NOTE:

Cookie settings