Salient Soft

I experimented with mounting a backup image from a particular backup point on a job, using the Backup software.
This worked fine, and a new drive letter was created which could be browsed directly via windows explorer.
I was not clear how to dismount the image, and the documentation said that it would only remain mounted until a reboot anyway.

In fact, after rebooting, the image remained mounted in error even if the backup disk was not available (obviously it could not be fully browsed). I managed to remove it consistently by de-assigning its drive letter in disk management, then rendering it offline in disk management, and then using device manager to delete the UIM device for the mounted image, which appeared under disk devices. This worked ok providing all the steps were done in the right order, otherwise it appeared to remain around after a reboot.

After trying again in the backup software, I found it was a simple user error – the mount screen allows selection of a drive letter, and if one is already selected you can select “None” again to remove it and dismount the image. This was not immediately obvious the first time around – I failed to notice that “None” was available in the list as it was hidden and you need to explicitly scroll to the very top of the list to see it.

Once I dismounted the image this way, it worked immediately and completely removed the image and the device even without a reboot.

Comments Off on Dismounting a Paragon Backup Image

… as above – I received the following error in relation to a PrimeNG p-dropdown used with a p-dataview:

Error: The target entry-point “primeng/dataview” has missing dependencies:
– @angular/cdk/scrolling

This issue is covered here.
I haven’t seen this before, but installing @angular/cdk resolved the build failure. This appears to be a transitive dependency issue which should have been resolved by my dependencies on PrimeNG.

Comments Off on PrimeNG 11/Angular 11 build fails due to missing @angular/cdk dependency

I was using a JSON file to hold external configuration for an agular application, using the pattern detailed previously here, and the loading mechanism detailed here.

The configuration pattern used allowed parameters to be overridden dynamically from query string parameters, so that for example you could choose an application theme in your URL.

I wanted to further extend this to allow sticky configuration parameters using localStorage, in particular to support a sticky pinnable title banner as detailed previously here. The aim was that both the query string support and the sticky localStorage support would be encapsulated in the configuration pattern and all transparently handled by the existing configuration service. The service would be enhanced with a new method call to allow persisting of a sticky parameter to localStorage and to the loaded config, for example for my sticky pinnable banner, to allow calling to persist the new pin state when the pin state was changed via the pin button. The previous pin state would then be loaded when the site was subsequently visited. Sticky parameters would override settings in the JSON file, and query string parameters would further override both of the former, and a query string parameter would also be sticky and would persist to localStorage, so for example the previous theme selected in the URL would be remembered.

One challenge was that whilst the configuration structure conformed to a Typescript interface, I needed to dynamically update configuration parameters from query string parameters or localStorage. This meant using dynamic keys e.g. based on the querystring parameters. Whilst this was initially possible by casting the config structure and using a map style lookup with config[keyVariable], it was not possible to dynamically infer the type of a configuration parameter from the interface, noting that both query string and localStorage parameters are strings. Often this is not a problem, as the default javascript behaviour will quite often cope, but therein lies a danger. In one case with a boolean, my query string/localStorage parameter was of course a string, and when written to the configuration using a dynamic key name as above, it was written as a string rather than the boolean expected in the interface. This meant that the value ‘false’ was in fact interpreted as true, due to the standard javascript truthy behaviour whereby a non empty string counts as true.

In the end, my solution was to have a subsection in the configuration, called dynamicParams, which contained all these dynamic parameters. It was therefore a requirement that all the dynamic parameters were strings and that client code reading the configuration had to be aware of that and convert as required.

One useful feature was to use Typescript intersection types for the dynamic parameters section, as detailed here. This allowed me to specify the dynamic parameter names explicitly, to allow them to be read in code directly as for example using config.dynamicParams.theme. I could also use programmatic access as above using config[keyVariable].

The section of the interface definition to do this was as follows:-

export interface AppConfig {
   appTitle: string;
   description: string;

   /* These parameters can be overridden from URL query parameters
    * and/or sticky local storage parameters
    * They must all be strings as are accessed by key programmatically */
   dynamicParams: {[key: string]: string | undefined} &
      {
         theme: string;
         pinBanner?: string;
         profileId?: string;
      };
   propertyDetail: {
      defaults: {
      photoLinkHoverText: string;
   }
   …

A particular point of note was that the intersection type using “&” was needed for this to work, rather than the union type “|”.

This solved the problem satisfactorily and all worked fine.

Comments Off on Dynamic Typing issues with Typescript/Angular 11

In angular 6 I was able to load custom static scripts, either via script tags in index.html, or dynamically, by placing the scripts in the project root (when using ng serve), or in the dist/projectname folder when running the built application. I originally used this for externalised configuration per my original post here, initially using script tags in index.html, and later using dynamic script loading via APP_INITIALIZER, which allowed dynamically named config files derived from query string parameters, and also early dynamic loading of external scripts such as for Yoti.

However, in angular 11, these use cases all gave 404 errors on the script. Posts such as this one here pointed to the need to place static files under the assets/ folder (although the post used an earlier angular version than 6, so I would expect it to work). I tried this, and both the static and dynamic use cases then worked correctly. I suspect that this is due to changes in the packaging when building and using ng serve. I retried a simple new project with a static script called from index.html, both under 6.1.7 and under 11.0.6. Under the older version, scripts in the root folder worked, but under 11.0.6, I had to place the scripts under assets (or in a subfolder of assets). This clearly demonstrated and resolved the problem.

Comments Off on 404 error when loading external config script in angular 11

Originally I used ngAfterViewInit to perform some custom DOM changes in a component (adding a default title to certain dynamically added anchor tags).

Unfortunately this resulted in weird behaviour whereby the changes did not appear in the DOM. It appeared that the DOM was being rebuilt again after the lifecycle hook had been called, as initially in debug the changes could be seen on the page, then they instantly disappeared.

Switching to using ngAfterViewChecked resolved the problem, as noted in this StackOverflow post. Whilst there are efficiency issues to consider here, it is obviously essential that the lifecycle hook used is guaranteed to be called every time the DOM is updated. Note also that the first time through flag used in the above StackOverflow post did not work – clearly the DOM was still being changed after the first call to ngAfterViewChecked, so the first time through flag was dropped. This other StackOverflow post also discusses the same solution to the problem.

Comments Off on Angular changes DOM again after calling ngAfterViewInit

I did an npm-update of  my microapp-fabric-prototype and my microapp-dataview app.

This resulted in the upgrade of

"@angular-devkit/build-angular": "~0.8.2"

to:

"@angular-devkit/build-angular": "^0.13.4",

in package.json. This caused my microapp POC to fail.

When the host Microapp Fabric application receives a menu action from a menu item click, it dynamically creates an angular element in its microapp container; the element contains the target microapp.

This should result in the initialisation of the angular runtime environment for the custom angular element, including initialisation of the IOC/DI environment for the target angular element app. This includes creation of all the required components/services and calling of their various constructors.

Unfortunately, with the later version above, instead of initialising the app-config-service in the angular element, it tried to re-initialise the app-config-service for the host app a second time which caused the whole app to fail.

The precise reason for the issue is not known. Both apps have some services (such as app-config-service) which have the same name, and sometimes when debugging it can cause confusion when trying to navigate the source maps in the debugger.

However, as all the services and components for each app (the main app and any angular-elements) are correctly encapsulated, there is never a confusion between them, even though the script environment is common and not shadowed. (In this demo, we are using a shadow dom for the W3C custom elements/angular elements, but the javascript is not shadowed. This is correct, and allows angular to have a runtime environment which persists across the main app and all the angular elements, and manages them all correctly).

As I have found before, care needs to be taken when upgrading versions – this is quite often not straightforward and needs care to check out dependencies that cause failures. Care will be needed I suspect when upgrading from Angular 6.1.7 to Angular 7!

No Comments »

I had serious issues trying to upgrade an existing project, and it was not clear online what I should do.

The main persistent error was:-

./node_modules/raw-loader!./node_modules/postcss-loader/lib??embedded!./node_modules/sass-loader/lib/loader.js??ref–8-3!./src/styles.scss
Module build failed: Error: Node Sass does not yet support your current environment: Windows 64-bit with Unsupported runtime (64)
For more information on which environments are supported please see:
https://github.com/sass/node-sass/releases/tag/v4.8.3

The online information on this was not clear.

Initially I used a liberal combination of npm-update and npm-update –g on various things but still had the above error.

I reached a point of installing primeng successfully under angular 6 as detailed here.

I then tried hand editing the package.json file for the upgrade project, stealing the versions from the package.json for the primeng application. However this did not appear to help -I still had the above issues.

In the end a combination of the following resolved this:-

ng update @angular/cli

ng update @angular/cli

npm install –g node-sass@latest

npm install node-sass@latest

I think the key issue here was installing the latest node-sass. I also had some code errors to resolve in the application but I did mange to run it successfully.

No Comments »

Update 23/5/2018

I retried this using Angular 6 and the latest primeng.

Step 2/ below was not needed, and I did not install/reinstall gulp per step 3/ (not used this time – need to check/confirm re this)

The wiki steps referred to below, here, referred to using sass to build the css, but this command did not work for me even when I installed the node.js sass per here -  the –update command came back with an error.

I then gave up using sass to compile the sass files.

Because of this issue I still had to fix the theming, so tried to copy the css files as below rather than compile the sass. This time the themes folder was under src\assets\components.

I therefore created another skeleton app, installed primeng using “npm install primeng”, and then copied the themes folder from under node_modules\primeng\resources  to src\assets\components, overwriting the themes already there.

This added the css files that were missing.

I could then run the showcase with theming fully working, either using “npm start” or “ng serve” – either worked.

I did notice that the theming borders on the treetable component did not appear to work, but apart from that all the theming including theme switching worked fine.

Original Post

It is useful to have this running locally in order to can try out occasional code hacks on the example code to try out ideas or check how things work if the docs are not clear on a point, knowing that you have started from a working example.

The steps for this basically follow the wiki steps here. Note the following additions/amendments to the steps:-

1/ I cloned the repository from here. Having cloned I then listed and disconnected from the remote repositories, as the clones were just for local use:-

git remote –v

git remote rm origin

git remote –v

2/ Dependencies as follows were added to package.json as per instructions:-

  "dependencies": {
      "@angular/common": "4.0.0",
      "@angular/compiler": "4.0.0",
      "@angular/core": "4.0.0",
      "@angular/forms": "4.0.0",
      "@angular/http": "4.0.0",
      "@angular/platform-browser": "4.0.0",
      "@angular/platform-browser-dynamic": "4.0.0",
      "@angular/router": "4.0.0",
      "@angular/animations": "4.0.0",
      "core-js": "^2.4.1",
      "rxjs": "^5.2.0",
      "zone.js": "^0.8.4"
  },

Following this npm install was run to download all the dependencies

3/ In order to build using gulp as instructed (gulp build), I installed gulp first as per the instructions here:-

npm install --global gulp-cli

npm install --save-dev gulp

4/ I then ran npm start to run the showcase, which defaults to http://localhost:8080/

The showcase ran ok locally but there were some issues with the theming – the theme had a transluscent background on the menus and dropdowns for example which did not correctly occlude the text underneath. The live showcase on the PrimeNG site did not have this problem.

On investigation it appears that the theme files are under the main resources/themes directory, but are not being sass compiled from scss during the build so there are no .css files there. The gulp file for the project, gulpfile.js, does not have any entries that do sass compilation so this may be an omission/bug in the version I had downloaded.

The showcase does not use the primeng under node_modules – it defines its own primeng package such that if you try to enter npm install primeng to install the themes in the normal way as part of the npm installed package, you get an error from npm about the duplicate primeng.

My workaround was straightforward – I just copied the theme folder and all subfolders from under the node_modules\primeng\resources directory in another application folder to the projects top level resources directory (in fact I used the primeng-quickstart-webpack which I had already set up) – any other project where you have installed primeng will do. This solved the problem by providing all the css files for the themes, and the themes and theme switching then worked.

As I have no requirement to do a full working build for the showcase this is no problem.

I checked for other posts about theming issues and found a couple of StackOverflow posts about theme issues with Webpack here and here. These may prove relevant for future development.

No Comments »

I had a bug whereby my view was emitting the same place document twice. This was strange as the database clearly did not contain 2 copies of the document. I had seen what appeared to be a similar issue before bud at the time did not track down the cause.

It turned out to be a bug in the view definition. The original (buggy) version follows:-

function (doc) {
  if (doc.type == ‘place’) {
      emit([doc.address.postTown, doc.address.locality, doc.name, doc._id, 0], null);
      emit([doc.address.postTown, doc.address.locality, doc.name, doc._id, 1], {_id: doc.placeFeaturesId});
  }
}

The problem with this is that when doc.placeFeaturesId is null/undefined, the second emit emits its key plus an “_id” with an undefined/null value in the generated json. The result of this is that when using ?include_docs=true to include the documents, CouchDB applies a default behaviour due to the null, and emits the place document again a second time. The following fix prevents the second emit when there are no placeFeatures present, which prevents the place document being emitted a second time. This solves the problem:-

function (doc) {
  if (doc.type == ‘place’) {
      emit([doc.address.postTown, doc.address.locality, doc.name, doc._id, 0], null);
      if (doc.placeFeaturesId) {
        emit([doc.address.postTown, doc.address.locality, doc.name, doc._id, 1], {_id: doc.placeFeaturesId});
      }
  }
}

The lesson here is to be careful to handle undefined or null values in the view code when emitting entries in a view definition as this can cause strange behaviour such as the duplicates above.

No Comments »

I was using a button component to encapsulate the primeNG one, to allow it to responsively change to an icon only button at smaller screen widths. Whilst in theory I could have dynamically modified the internal primeNG button CSS, this was complex and I did not want  to become tightly coupled to it. My button component therefore simply selected one of 2 buttons via a media query, setting the unwanted one to display:none.

I wanted any classes added to the top level ss-button to be set on the underlying primeNG buttons. One use of these buttons was in a home brewed tab component, and  I was dynamically changing the button colour via ui-button-primary, ui-button-secondary so that the active tab had a ‘primary’ coloured button and the inactive ones were ‘secondary’ which caused them to become uncoloured ghost buttons – ideal for my requirement.

During refactoring to replace the ‘full size only’ primeNG buttons with the resizing ss-buttons I introduced a bug and the colour change failed to work. The initial (incorrect) refactored code was as follows:-

ss-tab-toolbar.component.html

<ng-container *ngFor="let tab of tabs">
  <app-ss-button [label]="tab.label" [icon]="tab.icon" (click)="setActiveTab(tab)"
          [ngClass]="{'ui-button-primary': isActiveTab(tab), 'ui-button-secondary': ! isActiveTab(tab)}"></app-ss-button>
</ng-container>

ss-button.component.html

<button pButton type="button" [title]="label" [label]="label" [icon]="icon" class="ss-button icon-text"
        [ngClass]="class" ></button>
<button pButton type="button" [title]="label" [icon]="icon" class="ss-button icon-only"
        [ngClass]="class" ></button>

ss-button.component.ts

@Component({
  selector: 'app-ss-button',
  templateUrl: './ss-button.component.html',
  styleUrls: ['./ss-button.component.scss']
})
export class SSTabButtonComponent  {

  @Input() label: string;
  @Input() icon: string;
  @Input() class: string;

  constructor() { }
}

The issue was that I was using [ngClass] dynamically to update the classes on the <app-ss-button> in ss-tab-toolbar.component. html. This used to work for the PrimeNG buttons, but now would have no effect as the classes need to be changed on the child buttons not the encapsulating parent. A simple change of [ngClass] to [class] fixed the problem, as the parent style change then updated the property on the parent component which was then picked up by the children correctly.

modified ss-tab-toolbar.component.html

<ng-container *ngFor="let tab of tabs">
  <app-ss-button [label]="tab.label" [icon]="tab.icon" (click)="setActiveTab(tab)"
          [class]="{'ui-button-primary': isActiveTab(tab), 'ui-button-secondary': ! isActiveTab(tab)}"></app-ss-button>
</ng-container>

Happily the dynamic nature of angular meant that this worked perfectly for tab changes – the change on the parent class was propagated correctly to the child and the button colours changed correctly.

I was wondering initially whether I would need to involve observables to make this work but this was not the case – this kind of dynamic propagation pattern is worth remembering in future.

No Comments »