I can guess your number in 6 steps (using linear algebra)

by billkrat 27. February 2015 03:50

I’m taking a linear algebra course and was tasked with an assignment to demonstrate how it can be used to perform a “magic trick”.   The instructor gave a couple of examples which got me thinking – “how can I use it to guess a persons number and reveal it to them”.  The answer follows:

Grid1

Grid2

How it works => CLICK HERE

Tags:

Algebra

Online 3D model editor and artist website

by billkrat 24. February 2015 19:12

Source: SculptFab-face.obj  (this is actually a text file)

The above source file can be loaded into SculptFab’s online editor at:https://labs.sketchfab.com/sculptfab/ 
Note: site worked with FireFox and IE 11.

Sculptfab is a very simple tool letting you sculpt 3D models in the browser and publish them in 1 click to sketchfab.com.   Tutorial is available at THIS LINK

Face

I created an account at SchetchFab and with a click posted my 3D face to https://sketchfab.com/billkrat
Note: site worked with FireFox and IE 11.

Scetchfab

Tags:

3D

The type name or alias … could not be resolved. Please check your configuration file and verify this type name

by billkrat 18. February 2015 08:38

This one took me more time than I care to admit as well as a number of dead-end Bing searches…   There are any number of reasons why Unity won’t load a configuration file, i.e., typo in “type” or “mapto” attributes, but in my case these were correct – I even copy/pasted both namespace and class names to ensure there was not some unforeseen typo.

What I didn’t quickly find was resolution to my issue which was that you must have an <assembly name=”” entry in your configuration file.  Once I added it Unity happily loaded the configuration file.

Screenshot

GhostDocUtil – adding custom pages to your .chm file

by BillKrat 16. February 2015 20:38

            Source: GhostDocUtil.zip (Visual Studio 2012 and greater)
  Prerequisites: Html Help Workshop  
                           When prompted associate .HHP file with C:\Program Files (x86)\HTML Help Workshop\HHW.EXE
Documentation: GhostDocUtil: Help folder contains a GhostDocUtil.chm file.   See Quick Start for more details

The Ghost Doc application is an amazing tool for documenting source code, I particularly like the preview feature.  The only issue I encountered was that it only generates an API listing, e.g., you’ll only see the area shown in the red box in figure 1. 

I found a way to back door the system so that I could add custom pages which prompted me to write a utility to automate the process.   GhostDoc generates all of the files necessary for the Html Help Workshop to compile a new .chm – thus providing the means to add custom pages.  However, after successful building the .chm it deletes all of the files (more specifically the temporary folder).  So the key was to figure out a way to prevent this from happening at a point when processing was completed.   The solution was to open the .chm after a successful build and then build the help file again, this generates an error message (which I ignore) which opens the door for GhostDocUtil to automagically generate the custom pages.

The entire process takes six manual steps which are outlined in the Quick Start page (see prerequisites above).  The important part is that you can author your custom pages using a normal .htm page as shown in figure 2. 

The GhostDocUtil.chm pages combined with the GhostDocUtil source code (which was used on itself to generate the documentation) should give you the information necessary to create custom pages for your project’s documentation

ChmPage
Figure 1 screenshot of .chm after processing custom pages

SolutionFolders
Figure 2 solution folder screenshot

GhostDoc solves the age old problem of documentation

by BillKrat 15. February 2015 10:02

See GhostDocUtil for information on how to create custom pages in your .chm.

Historically the problem with technical software documentation has been keeping the UML diagrams and/or documents in sync with the code.  GhostDoc Professional and Enterprise now offers a solution to the problem.

GhostDoc not only provides an easy means to generate XML documentation, it also supports the ability to easily add images and preview documentation.  In figure 2 below I show the UML sequence diagram that represents the business logic flow of the BootstrapperBase class.  In the future, if I am working on this section of code all I would have to do is right click on the code and request a preview (reference figure 1).  It will show me the documentation preview shown in figure 2 (right pane) where a picture will truly say a thousand words – particularly when I reference this diagram from the bootstrapper class that will derive from it.

As for up-keep, all I have to do is keep the XML documentation current as I modify the code and after updating the UML diagram I’ll then then capture a screenshot of it saving it using its use case designator, in this case SD0300-020-075-010.PNG.  Walla!  We’re documented and can move on without looking back; all references to this use case within documentation will be updated when I produce the .chm file.  Likewise it will be current for the next preview.

This provides a great return on investment making it worth the time to clearly document each process in a class. 

I will be using this for my open source project http://PasswordMgr.CodePlex.com which will utilize my Prism Light framework

SolutionShot
Figure 1 right click on code, select GhostDoc Enterprise, and request a preview

SequenceDiagram
Figure 2 code with preview

MVPVM - Overview

by billkrat 15. February 2015 05:04

MvpVm
 
Read article on MSDN

The MVC Presentation Model pattern was the development pattern that was used for early development, it is synonymous with MVVM. Some of the problems encountered with this pattern were ViewModel bloat, inability to reuse components, pollution of domain objects with view state, and no access to view components (as only data binding was used).

Because of these limitations our late architects evolved to the MVP (Model-View-Presenter) pattern - reference Martin Fowler article on GUI Architectures for more information.

John Gossman, father of MVVM, noted “On naming, my opinion at this point is the the Model-View-ViewModel pattern is a WPF-specific version of the PresentationModel pattern. PresentationModel is a lot easier to say and to write, and is more widely known...but for now I'm sticking to M-V-VM terminology in my own thinking in order to capture the WPF-ness and to avoid any interpretation conflicts”,

I refer to the WPF specific version of MVP as the Model-View-Presenter, ViewModel (MVPVM) pattern for the same reasons noted by John.

 UC0100-AnOverView

If In my experience I have found that developers are well aware of pattern rules, such as not having a View referenced from the ViewModel, but I found they lost track of the reason why; in case you are one of those developers, the reason is because it prevents reuse of the ViewModel; the ViewModel should be able to be accessed by multiple  views depending on your use case (more on this below). 

Reuse is the primary reasons we also have a rule that says we don't want to put code in the Views code-behind.  So we defeat the purpose of this rule if we put all of our code in the ViewModel because we essentially turn our ViewModel into a View’s code-behind without the benefit of being able to access the view components; worst yet, we cannot share it with other applications or platforms. 

The MVP pattern allows our developers (as a rule) to access the View and ViewModel equally, this permits the components to remain decoupled allowing them to be reused by other applications and platforms.  Some developers may feel that MVPVM is an enterprise development pattern not to be used with small programs, however I suspect most of us have experienced that small program that turned into a large application – they have a tendency to grow feet, suffer from scope creep (once client knows what they can have), and can become impossible for reuse  of components.

Many years ago I wrote a small application for the Amarillo Medical Group, it was for handheld device that was going to allow the doctors to track their billing.  After the first release some doctors wanted it on a laptop so I had to write a second program the worked on the desktop platform.  Later, some doctors wanted access from a website so the small program turned into three applications.  One day a doctor asked for a change to the application and couldn't understand why he was charged for three application updates - he felt it should have been a change in one place and this caused frustration since the apps looked exactly the same.  It was this experience that sent me down road looking for a way to develop one program that could be used for all platforms.  I started the journey on my open source project http://PasswordMgr.Codeplex.com.  Along the way I learned the importance of creating reusable, decoupled components and the value of MVPVM as MVP was a pattern created to achieve this goal; those who do not learn from the past are doomed to make the same mistakes.

In the PasswordMgrV3 folder of the Codeplex open source project http://PasswordMgr.Codeplex.com, we created an ASP.NET MVC application and pulled all of the login view models into a reusable portable class library.  This will permit us to create views that can reuse these view models from the desktop, tablet and phone platforms (as well as the Web platform).  So you can see that If we tie a view models business logic to one platform we won't be able to easily reuse it on the others.  So as MVPVM dictates we’ll move the business logic into the controller or presenter as applicable.   The goal is that the use cases in gray below can be reused cross-platform, on all devices, using one set of code written in C#.  For this purpose the Prism Light framework was born.

UC0100-Relationships

Prism (light) for Xamarin

by billkrat 14. February 2015 10:26

Prism Light

Source code: CodePlex 
Change set: 107164

I am excited about the technology that will permit us to develop cross platform applications; Xamarin provides the ability to program to IOS, Android, and Windows devices.  This is a band wagon I am ready to jump on and fortunately there is a toolkit that is paving the way to make this easier for us – the MVVM light toolkit.   Although I will be using MVPVM for my application framework design, I will be able to use the components of the toolkit to make this job easier.  

It was great to see that Unity is supported by the portable class library, I’ll use this instead of SimpleIoc but I didn't see any support for Prism just yet.  This will require me to roll my own until something is available,  unlike my efforts in the past (my PasswordMgrV2 folder has a Prism portable class library that I ported) I am going to take a more agile approach and only create the Prism “like” components that I require at each phase of development.  I’ll use the MVVM Light toolkit components where applicable, in lieu of creating a Prism “like” component.

The goal for the POC was to modify the MVVM Light template as little as possible while providing MVPVM capabilities.  The end result is shown below for this phase of development:

AppScreenShot

The above screenshots shows four modules (top pane).  A module is the equivalent to what you would get if you created a single MVVM Light template – a single view that represents a use case.  The four modules in this POC are the menu, status bar, user (left pane), and generator (right pane).  At this phase of development they all have the same module code shown above with different views containing the XAML shown below:

    <Grid>
        <TextBlock FontSize="18"
                   FontWeight="Bold"
                   Foreground="Purple"
                   Text="{Binding WelcomeTitle}"
                   VerticalAlignment="Center"
                   HorizontalAlignment="Center"
                   TextWrapping="Wrap" />
    </Grid>

The modules reside in a project called MvpVmDesktop while the MVPVM framework resides in project MvpVmPcl, it a portable class library that should port over to Xamarin, we’ll know more when the Visual Studio 2015 Starter license becomes available in a couple of months.

MVVM light developers will feel right at home when they open the POC project as all of the binding and wire-up is the same.  I made only the changes shown in red boxes (image below), the bootstrapper is the only new class. 

Prism developers should feel right at home with bootstrapper, EventAggregator, and module concepts.  I did implement my own ILogger (not Prism’s LoggerFacade) at this point so that I can subscribe to logger events – this allows me to easily send logging information to a textbox (coming soon).  This framework is barebones but functional as of this change set.

You’ll notice that in the solution there is a web project (MvpVmWeb).  This web project uses the MVC template, I removed the view models from it and moved them into the MvpVmPcl (portable class library project) so that I could use them in the log-in module of the MvpVmPoc (desktop app); reuse of views and view models is where MVPVM shines.

Since the ASP.NET MVC website uses these view models I would not want to add any business logic to them.  In MVPVM it is the each module’s presenter (coming soon) responsibility to populate the view models as required allowing the views and view models to remain completely decoupled.

Note: as this framework progresses there will be a Windows Phone, Tablet, Desktop, and Website password manager application that utilizes the same code and view models – only the UI code will be different.   When it comes time for IOS and Android, via Xamarin, I should only have to create those UIs as well.  NO CODE will reside in views and view models (outside of visual state and bootstrapping) making the transition to other C# supported platforms easy.

MvvmLightCodeAdded

The temp directory in chart handler configuration is not accessible

by billkrat 21. January 2015 08:03

If you encounter this error you will need to add permission for IIS_IUSERS or if applicable NETWORK SERVICE to read, write, and modify.   To do this, select your web application folder under inetpub\wwwroot using the windows explorer and then right click on folder, select properties, security tab, edit button, select IIS_IUSERS or NETWORK SERVICE as applicable, and then click the modify and write checkboxes.

Excerpt from https://msdn.microsoft.com/en-us/library/ff647402.aspx follows:

File Access

The Network Service account has Read and Execute permissions on the IIS server root folder by default. The IIS server root folder is named Wwwroot. This means that an ASP.NET application deployed inside the root folder already has Read and Execute permissions to its application folders. However, if your ASP.NET application needs to use files or folders in other locations, you must specifically enable access.

Granting File Access to Network Service

To provide access to an ASP.NET application running as Network Service, you must grant access to the Network Service account.

To grant read, write, and modify permissions to a specific file

  1. In Windows Explorer, locate and select the required file.
  2. Right-click the file, and then click Properties.
  3. In the Properties dialog box, click the Security tab.
  4. On the Security tab, examine the list of users. If the Network Service account is not listed, add it.
  5. In the Properties dialog box, click the Network Service user name, and in the Permissions for NETWORK SERVICE section, select the Read, Write, and Modify permissions.
  6. Click Apply, and then click OK.

Your ASP.NET application can now write to the specified file.

Tags:

IIS

Debugging “composition produced multiple composition errors”

by Billkrat 22. November 2014 04:40

 Programming with Prism using MEF as an IOC container is very powerful but it can generate some intimidating error messages.  During a minor refactor where I had moved module tracking components out of its own project into a more global MEF infrastructure project I received the following compile error that indicated I now had 8 root causes to numerous composition errors – the only clue I was going to be given was that there were duplicate exports…. 

001-Error

The cause was quickly found by stepping through ConfigureAggregateCatalog() method while viewing its Parts property and observing the parts listed after each AssemblyCatalog is added.  In this case I found the problem early in the process within a baseclass that loaded the MefInfrastructure project.   Before the refactor I was referencing the CallbackLogger in MefInfrastructure and the ModuleTracker in a separate assembly – now that I had moved the ModuleTracking code into MefInfrastructure I was effectively loading each of its Parts twice!

002-Cause

After removing the offending code I was back in business :)

004-Working

ToolBarTray - Programmatically adding ToolBars (Prism/MEF)

by billkrat 14. November 2014 07:31

Source Code: PrismMefPocV2.zip (4 meg)

It is surprisingly hard to find any references on how to programmatically add ToolBars to the WPF ToolBarTray control – as a matter of fact, I never found an example!  Not in any books on Safari Books Online nor researching the internet; everything demonstrates how to do it from XAML alone.   The problem with this is that I have a reusable View and ViewModel sitting in an external project (MefInfrastructure, ref figure 2) that I can’t hardcode XML ToolBars into if I hope to reuse them with other Windows – it has to be done programmatically.

Since I’m using Prism, with MEF as the IOC container, I need to first create a toolBarCollection (ref line 87 in figure 1) and then insert the instance into my MEF container (the next line).  

As for the button clicks, on lines 83-84 of figure 1, I am handling all button clicks for this ToolBarTray with the button_Click() method on line 91 – it will simply open a message box displaying the content of the button for this phase of POC development.  UPDATED:  button click in source code now loads module, ref figure 3.

Note: for those of you not using Prism/MEF – examine the code underlined in yellow in figure 2 to see how to take the collection on line 87 of figure 1 and programmatically add it to the ToolBarTray.

002-Source
Figure 1

With the ObservableCollection<ToolBar> instance exported, I can now easily import it into any applicable class, e.g., in this POC I am importing the values into the ToolBarViewModel (ref figure 2 below on line 11 in the top right pane).

So anytime I import the ToolBarViewModel, as I do on line 21 in figure 1, the ToolBarCollection property of the ToolBarViewModel will be automagically populated with the instance stored above.

With the ViewModel now populated with the ToolBar collection to be utilized by the view, it is now time to attach the ViewModel to its View, this is done on line 43 in figure 1 (above).  The magic happens in the ToolbarView code-behind (reference code underlined in yellow below) within the constructor.   When the DataContext changes it will take the contents of the ToolBarViewModel.ToolBarCollection and programmatically add each ToolBar to the ToolBarTray (x:Name=CtrlToolBarTray).

This permits all of the components in the MefInfrastructure project to remain completely decoupled, neither the ToolbarView nor ToolBarViewModel have any dependencies of external components.

001-Decoupled
Figure 2

UPDATED:  Source code updated to launch modules B, C, and F upon applicable button click.  All of these modules are configured to load “on demand” so they are not automatically loaded – line 83 in figure 3 loads the module.

003-Updated
Figure 3