Inventor API: Custom add-in #3 – Working with the API, implementing the functionality

Hello there!
It’s time for the last part of our small tutorial on writing Inventor add-ins. Today we’ll write the actual implementation of the functionality described in previous post and explain some other small details. So, let’s get to work!

INVENTOR HANDLER

Our main functionality will be performed by a single class – InventorHandler (which will also be abstracted by IInventorHandler interface). It’s going to have only one public method AutoBreak() which will be responsible for applying the break to correct view. Let’s start with constructing it.

Private fields

It consist of three private fields: invInstance which stores reference to current instance of Inventor apllication, settings which stores reference to settings model and comparer which stores reference to IComparer implementation for sorting drawing views descending, area-wise.

This implementation is actually an internal class within our InventorHandler class. We won’t need that anywhere else.
Next, we have static list which contains orientation types which can work with our auto-break. This means that all views which are different orientation will not be take into consideration when executing auto break.

That list contain only perpendicular projections (back, left, right etc.) and the one called kArbitraryViewOrientation. This is the type of all views generated from a base view. This mean that although isometric views are not present this our collection the add-in will break that kind of view if it is created from an existing view.
The last thing is a predicate that is used for removing all views which are orientated differently than types allowed in the collection that we have just explained.

Constructor

The constructor for our InventorHandler class is very simple. It sets invInstance and settings to those given as arguments and instantiates new DrawingViewSizeComparerHelper class.

AutoBreak();

Now, let’s go through our only public method in the class:

It takes current active document in running Inventor application and sets a reference to in in a local variable drawing as a type DrawingDocument. Although property ActiveDocument of invInstance is of Document type (which is more general than DrawingDocument) it is safe to set is as DrawingDocument as our button to execute will be visible only in Drawing ribbon, therefore we’re sure that the active document IS DrawingDocument.
Next, we set another local variable which is of type DrawingView and assign result of getBiggest method executed with argument of drawing.ActiveSheet. This gets currently activated sheet in active document. If it’s null (meaning no drawing views are in the sheet) or it is too small to be broken the add-in will display a message and terminate execution of AutoBreak method. Otherwise, it continues.
Now, it checks if there already is a break applied to the view. If it is, again, it displays appropriate message and terminates.
Next step is to determine start and end points for the break. They are of type Point2d and they are set as local variables inside the method’s body. To give them appropriate values one of two methods is invoked: horizontalPoints or verticalPoints. These methods return boolean whether it is possible to break, and outs break points.
The last step is to apply the break:

It is done by executing Add method of BreakOperations collection in a view. It takes several arguments, as follows:

  • BreakOrientationTypeEnum – break orientation;
  • Point2D – start point;
  • Point2D – end point;
  • BreakStyleEnum – style of break, rectangular or structural;
  • integer – display level, in our case we pass default value of 5;
  • double – gap between left and right part of the view;
  • int – number of symbols, works only for rectangular view;
  • bool – propagate to parent view, defines if the break will be visible in parent view, in our case we pass default value true.

And that’s it. That’s the workflow. Now, as you probably noticed the method described above uses few private methods. To fully comprehend how the add-in works it is necessary to describe them as well.

DrawingView getBiggest(Sheet _sheet)

This method finds the biggest view in the given sheet. All views which are not orientated correctly (remember the list of ViewOrientationTypeEnum?) will be excluded from the selection.

bool isHorizontal(DrawingView _view)

Simply checks if a view is wider than higher and returns true if does.

bool canBeBroken(DrawingView _view, bool _isHorizontal)

This one checks if a view is sufficiently wide for horizontal break, or sufficiently high for vertical break. Minimum height/width is 5 cm plus gap. Remember that the API operates on centimetres expresses in variables of type double.

bool horizontalPoints/verticalPoints(DrawingView _view, int _percentage, out Point2d _start, out Point2d _end)

These two counterparting methods calculate start and end points based on given view and percentage of the view that needs to be removed. Methods return boolean whether a break can be applied and outs the points.

Converters

As some values from settings model are of simple types while methods exposed by the API require some arguments of different enum types there are two converters in the InventorHandler class: one is to convert boolean to BreakOrientationEnum

and the second one is to convert integer to BreakStyleEnum:

And that’s it if it comes to our InventorHandler class. However, to make the add-in actually work there are some changes needed in StandardAddInServer class.

CHANGES IN MAIN ADD-IN CLASS

First of all, we need an instance of InventorHandler. We’ll create a private field for that and initialise it in the constructor:

The last step is to modify action that is fired when the ‘Apply’ button is clicked:

And that’s it. The add-in is now functional. See the demo below:



FINAL REMARKS

There are two things I want to mention at this point. First, is about embedding the stdole assembly. When it’s added to the project and the project is built you will get a warning message:

Although, it does not affect the build you can get rid of these messages by setting Embed Interop Types property of stdole reference to false:

The other things is a word of explanation about NameValueMap interface. It used (amongst other uses) in the API to pass parameters in the events (as in our case events fired by clicking buttons). It works similarly to dictionaries, it stores pairs of name (which are strings) and values (which are of type object). I will not describe it in details (if you need that, simply go to its metadata in Visual Studio), but now you know the main thing – it is name/value pair to pass event parameters.

 

CONCLUSION

A vast portion of things can be manually done in Inventor can be automatised. However, the freedom in modelling that software gives you makes it really difficult to develop universal add-ins that will work always, no matter what you’re modelling. But all of translation, conversion, export things can be easily worked with. I know that there are some add-in that allow to generate models of sprockets, pulleys etc. and that works perfectly.
The hard thing when developing add-in is debugging. Possibilities here are limited because every time you want to debug you need to build your project and run the application, and you won’t get any error messages – either the application will crash, the add-in will be disabled or it won’t be executed.

To make things clear – I have worked with that software as a professional for more that 5 years and I am a big, big fan. I have experience with others systems, but this one seems to be most user-friendly, most of the features works as you would expect and has that professional-feel. But, it’s not a review, so I’ll stop here.
Thanks for your time, I hope that it is in any way useful for you. Good luck!
Michal

GitHub repo: https://github.com/mickaj/AutoBreaker-Inventor

Inventor API – Custom add-in Part #1
Inventor API – Custom add-in Part #2

Inventor API: Custom add-in #2 – Functionality and UI

Hello!
Writing our add-in for Inventor continues! Agenda for today’s post is simple: first I will write a word or two about what is the functionality of the add-in, then I will present the UI and what settings it provides, finally I will present the code.

FUNCTIONALITY

So, what will the add-in do? It allows user to place initial break to the biggest view in the drawing. It is rarely required in real world but the purpose of this demonstration is not to write something widely useful but to present how to write basic add-in for Inventor. Nevertheless, I wouldn’t be surprised if someone finds actual use for it. Feel free to do that 🙂
Inventor allows to set some parameters of the break. First and the most important is orientation. In our case that will be determined not by the user but automatically depending on proportions of the view. The rest will be allowed for customisation. As this is not an Inventor tutorial I am not going to describe in details how to manually add the break and what exactly can be customised. For such pieces of information you can easily find something on YouTube (for example this[1]).

UI PRESENTATION

As our add-in is very simple its UI is equally simple. Combo box for break style, slider for number of symbols (for structural style), text box gap which value will be converted to double and is expressed in centimetres, and slider ratio of how much of the view will be removed (minimum is 10%, maximum is 90%, however if the view is to small the break will not be applied). This small dialog is built in WPF and follows the MVVM pattern.

CODE

As this add-in will use WPF user interface I want it to follow the MVVM pattern, therefore we need model and view-model.

Model
So, let’s start with the model as this one is the simplest:

Style parameter is represented by an integer property backed by a field. The property setter allows only two values: 0 and 1 – that’s how two possible options are represented. Other possibility could be for instance a boolean, however integer is simpler to use with combo box. Similar situation with Symbols where setter allows only 1, 2, or 3 to be assigned; and with Range which can vary from 10 to 90. Gap is auto-property of type double. Class constructor sets initial values which are hard-coded. Natural extension would be to save those values somewhere so they are saved between sessions, however it’n not the point at the minute. The model class SettingsModel is additionally abstracted by ISettingsModel interface.

View-model
The view-model is slightly more complicated, but still quite simple.

First and foremost – it implements INotifyPropertyChanged interface. Fields and properties reflect the model, there are two things that require explanation. Range field/property backing field is of type double which is consistent with its counterpart in the model, while property is of type int which is consistent with slider’s value property. Gap field/property is of type string which will be bound to a textbox. The view-model also contains reference to model which is set via default constructor, constructor also assigns values from the model to respective fields in view-model. There is only one method which is used to save values from view-model to model; and there is only one command which invokes SaveToModel() method and closes settings dialog.

As mentioned SaveCommand is used to save values from view-model to model. It can be executed only when Gap value in view-model can be parsed to double. Execute(object parameter) method casts parameter to type Window and invokes its Close() method to close the window. This require passing open instance of settings window to command parameter, which will be explained below.

View
Now, the view. There is one trick with WPF windows in Inventor add-in. If you try to add a WPF component to the project you will see that only user control is available, but the problem is that we need a window. A way to tackle that (source[2]) is to add what we can – a user control, and then change it to window. You need to do that in XAML code of the window and in the C# code behind. In XAML change root node to <Window>…</Window>, in C# code modify your class so it inherits from Window not from UserControl. And that’s it.

The only intresting thing in the XAML code above is how current instance of window is passed as command parameter:

The command parameter value is set to binding with RelativeSource set again to RelativeSource in FindAncestor mode with type of Window. This way  the current instance of window will be passed as command parameter which in turn is closed by the command.
Other than that, there are not exceptional things in the XAML, simply built UI with typical binding to view-model.
What you probably noticed, is that data-context is not set, and instance of view-model is not created in XAML, which requires the view-model to have parameter-less constructor, therefore some changes to add-inn StandardAddInServer main class are required.
Another thing worth mentioning is that closing (without saving settings to model) by clicking ‘Cancel’ button is achieved simply by an event assigned to that button, not by a command. This way to do that is much, much simpler than a command and because of the fact that it doesn’t interact with neither model nor view-model it doesn’t break the MVVM pattern.

Updates in StandardAddInServer
First thing that we need to do is to instantiate a model. The main class will be equipped in private field of type ISettingsModel […]

[…] which will be initialised in the class’ constructor.

The last thing we need to do is open the settings window when appropriate button is clicked. To do that we need a method that will be fired when the button is clicked.

The method above creates new settings window, sets it data-context to new instance of SettingsViewModel with current model as constructor’s parameter and finally shows the window as dialog.

And that’s it. Next (and the last) step will be to make ‘Apply!’ button to work. So, don’t forget to check my blog a little bit later.
Thanks, Michal!

GitHub repo: https://github.com/mickaj/AutoBreaker-Inventor

Sources:
[1] – https://www.youtube.com/watch?v=BzUAb9Qvu98
[2] – http://adndevblog.typepad.com/manufacturing/2015/11/wpf-window-inside-an-inventor-add-in.html

Inventor API – Custom add-in Part #1
Inventor API – Custom add-in Part #3

Inventor API: Custom add-in #1 – Introduction & modifying the ribbon

Hi!
Long time no see I might say… But there is a reason for that. As I mentioned in my previous post I turned my focus onto add-ins for Inventor and I have spent some time on that. Now, the plan is for short series of three post about writing add-in for Inventor. It will consist of three episodes: one – introduction and modifying the ribbon; two – description what the add-in we’re going to write in this series will do and its user interface in WPF; three – everything that resided under the hood and presentation how it works with Inventor.

TOOLS

In terms of tools there is nothing special needed. Obviously, Inventor needs to be installed and it’s SDK that comes along with the package. I do not own a licence for Inventor, but Autodesk allows for free 30-day trial to test their packages. The trial is for full package with no feature-limitations, however it is not allowed to use it for “commercial or for-profit purposes” [see here][1]. Writing these posts does not and will not violate either of those conditions, nonetheless if you are willing to write an add-in that will be used commercially you cannot do that with the trial. That having said we can move forward.
Once you have it installed it is necessary to install the SDK. It is an .MSI package you need to extract. It can be found in your Public Documents folder, then /Autodesk/Inventor2018/SDK. The package we’re interested in is developertools.msi. It will deliver some samples and – most important – project templates for Visual Studio. Unfortunately, the templates are for VS2015 so if you’re using VS2017 you will need to install older version as the templates will be installed only if Visual Studio is installed. If you still prefer to use VS2017 you can create project ins VS2015 and then open it newer IDE. I have not encountered any issues.

To sum things up, you will need:

  • Microsoft Visual Studio 2015 and optionally  Visual Studio 2017
  • Autodesk Inventor package which you can download with trial licence if you are not using it for commercial or profit purposes
  • Autodesk Inventor SDK developer tools installed that comes together with the software package

KNOWLEDGE BASE

Before I move on to the project I’d like to recommend two sources of knowledge about Inventor API. I already mentioned them in my previous post but to keep things organised I will do it again here.

  • Object Model Diagram – it is a PDF file that comes with the SDK developer tools and can be found in PublicDocuments/Autodesk/Inventor/SDK/DeveloperTools/Docs
  • this[2] repository on Git Hub. It contains thematically organised lessons on Inventor API with examples in C#

STARTING THE PROJECT

As mentioned before the templates are available for VS2015, so creating the project must be done in VS2015. All code written this series will be available on Git Hub. You will find a link at the end of this post.
Another thing that is important is to use correct version of .NET framework. I will be using Inventor2018 and it uses version 4.5. As I am aware most recent editions of Inventor uses 4.5 but if you want to be absolutely sure you can check that. To do that you need to go to your Inventor installation folder, then /Bin and open Inventor.exe.config file  in any text editor, then find <startup> tag section:

In the section above, the sku attribute defines version of the framework and in this case it is 4.5.
Having the project created you can save it, close and re-open in VS2017 if you prefer. Otherwise, you can continue in VS2015.
The last step would be to edit some values in AssemblyInfo.cs.

The project template is set up in a way that one the project is built all necessary files will be copied to appropriate location so the add-in will be visible in Inventor.
Having this done we almost can move on to modifying the application’s ribbon.

PROJECT REFERENCES

But before we start playing around with Inventor we need to add some references to the project. Right after project creation we only have references to autodesk.inventor.interop and System. We need bit more:

  • PresentationFramework – our UI will be build using WPF. You could use WinForms and I think that’s the preferred library, however I like WPF more. And that is the only reason for my decision.
  • System.Xaml – needed for WPF
  • stdole – that provides IPictureDisp interface that is going to be used for converting embedded icons to those usable with Inventor ribbons
  • System.Drawing – that provides Image abstract class and Icon class, needed for the same reason as above
  • System.Windows.Forms – that may seem suprising as I’ve already writtten that we’re going to use WPF. The reason behind the need of that reference is that AxHost base class to build our converter from Image objects to IPictureDisp usable with Inventor ribbons.

MODIFYING THE RIBBON

The application has several different ribbons. Which is used depends on what type of document is active and what environment is being used. To divide this series into episodes which are more or less equal length-wise I will just say now that the add-in will operate in drawing environment and will have two buttons: one to setup its preferences and the other one to run actions to be performed by the add-in.

First I will prepare two icon for our buttons. I downloaded some free icons from here. (I am absolutely talent-less if it comes to drawing). We need two size of each icon: 128×128@32bit and 16×16@32bit and they must be set as embedded resource. They will be stored in img folder in our project. So, to summarise: 4 files = 2 different icons x 2 different sizes.
Unfortunately, those icons cannot be used as they are. First, they must be converted to be of type IPictureDisp. To achieve that I’m going to use this[3] implementation (as proposed by Andrew Whitechapel at MSDN) of such converter:

As you can see our AxHostConverter class is an internal sub-class within our project main class StandardAddInServer. It won’t be used anywhere else so this approach is absolutely safe.
A method that creates instances of button definition as icons takes argument of type object, therefore they will be declared in StandardAddInServer class body as objects:

They will be in fact of type IPictureDisp in stdole namespace, but because of the fact that Inventor namespace also contains IPictureDisp type and avoid that confusion I will keep them as of type object. The process of retrieval from embedded resources and proper conversion will be performed by a private method getIcons() inside StandardAddInServer class:

So, that was the most confusing part. Now, it’s time start messing with the API. Adding our buttons to the application’s UI we need to start with defining some members in the class’ body:

The above fields will be initialised in another private method modifyRibbon(). The separate method is not needed however I like to have it separated just for a bit of clarity.
addInGuid string is copied value of Guid attribute from class signature. It will be later used to simplify a bit invocations of methods defining new buttons.

First two steps are easy, we just need to get some objects from currently running instance of Inventor, and that’s it.
Next step is to create command category for our add-in. It is done as in the code above, where arguments are as follow: strings for display name and internal name, and guid. Internal name is built as follows: “Autodesk:CmdCategory:our_custom_name“. This will add our category of commands that will be visible in UI customisation dialog:

Next, we need to access intended ribbon and one of its tabs. The ribbon we’re interested in is Drawing ribbon, the tab is Place Views.

As you can see they are accessible by their unique names and you must know them. They all can be found in mentioned earlier Git Hub repository here[4].

Next step – defining buttons:

It is achieved with use of ControlDefinitions and its AddButtonDefinition method. It takes several arguments (in respective order):

  • display name (string)
  • internal name (string) following scheme “Autodesk:command_category_name:button_name”
  • CommandTypesEnum – type of command, for UI elements it should be kQueryOnlyCmdType
  • add-in guid
  • description (string)
  • tool-tip (string)
  • standard icon (of type object, but it needs to be IPictureDisp)
  • large icon (of type object, but it needs to be IPictureDisp)
  • ButtonDisplayEnum – a way a button is displayed, in our case it is kAlwaysDisplayText

Once the button is defined we need to add action that will be performed when the button is clicked.

It the example above customAction method must return void and take one argument of NameValueMap which is set of name and value pair. It will be explained in one of later posts. For the time being, this method will only display a message box to demonstrate the buttons actually work.

The last step of defining a button is to add it to command category:

Now, we need to add panel to Place Views tab.

It is acheived using Add method in RibbonPanels collection in one of the ribbon tabs. It accepts arguments as follow:

  • display name (string)
  • internal name (string): “Autodesk:command_category_name:button_name“
  • add-in guid

Now, we need to add our buttons to the created panel:

In the example above AddButton takes three arguments:

  • button definition
  • boolean – use large icon
  • boolean – display text

So, that’s it. The ribbon is modified. After changes described above it looks like that:

Nothing more to add today. Check the links below and stay tuned for the next part!
Cheers, Michal

GitHub repo: https://github.com/mickaj/AutoBreaker-Inventor

Sources:
[1] – https://www.autodesk.com/licensing/trial-license
[2] – https://github.com/ADN-DevTech/Inventor-Training-Material
[3] – https://blogs.msdn.microsoft.com/andreww/2007/07/30/converting-between-ipicturedisp-and-system-drawing-image/
[4] – https://github.com/ADN-DevTech/Inventor-Training-Material/blob/master/Module%2009%20-%20User%20Interface/RibbonNames.txt

Inventor API – Custom add-in Part #2
Inventor API – Custom add-in Part #3

Inventor API: EventTimingEnum

Hi there,
Some time ago I started writing an add-in for Autodesk Inventor. That software exposes an API that allow to develop add-ins in C#/.NET. In this post I am not going to write anything specific about the project; it will neither be an insight into API specifics. I just want to give quick explanation about controlling events with use of EventTimigEnum.

Some actions in Inventor can take a bit of a while – for instance placing big component into an assembly. Therefore, it is possible to decide when custom action is performed – either before or after an event is completed.

Let’s start this demo with writing a method that will be executed when a new component is placed into an assembly:

Just a brief explanation to the code above: of course only a method with matching signature can be assigned to an event, and it is necessary to set value of HandlingCodeEnum output parameter.
Now, to attach that method to an event that fires whenever a new component is inserted to assembly you need to access Inventor instance. In this example it will be done in add-in Activate method.

Once that is done we can start Inventor and see what’s the result:



As you have probably noticed our CustomAction was executed twice. Sometimes this behaviour is desired, sometimes it’s not. Now, let’s modify our method to perform action only after the event is completed. To do that we need to check value of EventTimingEnum parameter and perform action whenever its value is what we desire.

Now, the message box will be displayed only after the event is completed. EventTimingEnum can have one of three possible values: kAfter, kBefore (which are self explanatory) and kAbort. The last value can be used in case we want to perform an action when an event is cancelled – for instance, when opening an assembly with lost reference user can decide to cancel opening.

It is also important to mention that not all events in Inventor are fired both kBefore and kAfter. Most of them are but you need to be aware that there are exceptions from that rule.

So that’s it if it comes to EventTimingEnum.
Unfortunately, there is not much about writing Inventor add-ins in .NET. What I recommend to check is first and foremost this GitHub repository:
https://github.com/ADN-DevTech/Inventor-Training-Material
It is complete course on Inventor API. There are presentations and code examples (in VB.NET and C#) for each chapter.
The other thing is class diagram delivered by Autodesk which comes with Inventor SDK installation. It can be found in Autodesk/Inventor/SDK/DeveloperTools/Docs in PublicDocuments on your C drive.
Regards, Michal

WPF: TreeView control

Hello there! It’s been a while since I finished GetNoticed contest and my last post here. I am done with SheetMetalArranger – at least for the minute. But that the contest is done doesn’t mean that I am done with programming. Not at all!

I started new project (maybe one time I will get back to SheetMetalArranger to improve it, but after ten weeks I need something fresh now). It doesn’t matter what the project is about at the minute (I will probably write a post or two about that), the important thing is that I’m continuing with WPF and the time has come to take a closer look at TreeView control.

Basics

TreeView control is used to display hierarchically organised structure. The best example is folder tree, for instance the one you have in Windows Explorer.

Here’s simplest example:

To build hard-coded tree you simply nest one <TreeViewItem> into another and build your structure. Notice that Header property is what is going to be displayed in your application. There are two other properties of TreeViewItem that should be mentioned here: IsExpanded and IsSelected which are pretty much self-explanatory but it is worth to mention them as they are fundamental for controlling behaviour of the control.

Binding

Binding a collection to TreeView can be easily achieved, it is no different as other controls. You simply bind a collection to ItemsSource property. But the tricky thing is that you need to reflect the hierarchy somehow. One way to do that could be binding a collection that contains objects of class TreeViewItem which is equipped in collection Items which contains child objects. Here’s the same example but with the difference that all data is stored in data model:

1) Lets start with the data model: our library node will consist of name, collection of books (stored as strings) and collection of sub-nodes.

2) Our actual data for the purpose of this example will be stored in static class with one static method GetData() that return instance of LibContainer

3) Our view model will consist of observalbe collection of TreeViewItems and in its constructor it will get data from the above static class. Inside the view model there is also one small private method that converts LibContainers to TreeViewItems

4) We set instance of view model and set it as data context. For example as below. Now, after that our tree view can be simplified just to only one line.

Load on-demand

The above example is nice and easy. It gets a bit more complicated when you want to load content of your tree view on-demand when content of your tree is huge and loading all data at once would be lengthy operation – I guess that’s common situation.

To achieve that we need to build custom class that will replace TreeViewItems in collection in our view model. That class must have: 1) collection of child items of the same class, 2) Parent, IsExpanded and IsSelected properties, 3) method to load children, 4) property that defines if the element can be expanded.

Here’s our example build this way:

What’s important in the code above is that Children collection must contain dummy element before actual elements are loaded. This is necessary because it would not be possible to expand the element, therefore it would not be possible to execute method that load further elements.

ViewModel class will now have only collection of TreeElement and will gather data from DataModel in its constructor.

Now, we need to define our TreeView control to display our custom items correctly. This is done by creating local style where we bind IsExpanded and IsSelected properties of TreeViewItem with counterparting properties of our custom TreeElement

And that’s it. This is how I use TreeView control. Possible extension to the above would be to create custom WPF control to handle custom types of tree elements and equip it with dependency property that exposes currently selected item. But that’s easy to do and isn’t in any way specific to TreeView.

So, thanks for today and good luck!

Sources:
WPF 4.5 Księga eksperta. Podręcznikprogramisty WPF 4.5! Adam Nathan (translated by Paweł Gonera, Ireneusz Jakóbik), published by HELION S.A 2005
https://www.codeproject.com/Articles/26288/Simplifying-the-WPF-TreeView-by-Using-the-ViewMode

 

GetNoticed DEV#10: Updates in demo

Good evening!
Although the demo was presented in my previous post I have updated it slightly: I added a progress dialog. This is to report how many items have been processed and how many of them is yet to be processed. The progress dialog also ensures the user that the program isn’t hanging without checking that in Windows task manager. Links to source code and installer below. And here’s quick video to demonstrate that:


 

Future of SheetMetalArranger
This project was developed for purposes of GetNoticed contest. At this moment I can’t say if I’m going to do anything more with it. Maybe I will, maybe I won’t. But if I do here’s what could be added/improved:

  •  efficiency: this is the most important factor to asses this program. In on of my previous DEV posts I wrote that 82% is good enough. And for the purpose of the contest it is enough, but if Arranger is to really serve its purpose it needs to be more efficient. It could be achiever by improving merging. Now only boxes which are the same width or the same height and are adjacent on equal edge are merger.
  • project files: it would be useful if arrangements could be saved and reopened later, JSON or XML would do the job
  • export: the demo just demonstrates calculated arrangement in its UI, it also saves generated PNGs in ProgramData folder on C:/ drive. But it would be much useful if a user could click a button and save them in required location. Also export to DXF would be handy and brief look at DXF standard allows me to think that it is achievable.

GetNoticed – my conclusion
As this is my last post for the contest I allow myself to write few words of conclusion. First and foremost the contest was a great boost of motivation. For me personally this is the biggest advantage. I am aware that my project isn’t the best, maybe it’s not even good. But keep in mind that I am still a newbie but I’m excited about the path that’s in front of me.
Thanks for everyone who read even one of my post.

Regards, Michal

SheetMetalArranger on GitHub
ClickOnce installer

GetNoticed IT#10: Factory method

Good evening!
Post number TEN in my GetNoticed IT series! In my DEV#8 post I mentioned that most likely my next IT post will be about tabs in WPF/MVVM but as you’ve probably figured it out it won’t be about tabs. It’s going to be about factory method design pattern.
So, factory method allows to encapsulate object creation. For instance, you can bring all logic that decides which object to create into one class. Or another example. In my project I used some singletons (which is considered to be an anti-pattern). This could have been avoided by using factory method (and it will be). In this case wherever I wanted to use an instance of singleton I would call factory method that returns object of my singleton instead of static property Instance.

How it works
Basic construction of that pattern is that you create abstractions of your factory class and of your – call it – product. Then you can create multiple different factories that return concrete product. Depending on what logic you will include in your concrete factory. Once you have that concrete factory you inject that into your class and let your class use that factory to instantiate concrete objects. It is very well explained by Christopher Okhravi in his just recently posted video. I highly recommend his videos.

Example
I prepared quick example for the purpose of this post. There are books and bookstore:

Pretty simple: book described by two properties and a method to display details; and a bookstore with a collection of books and a method to list all books in that collection.
Now, our books can be paper, ebooks or audiobooks:

All of the above can be stored in our bookstore. And we want to decide which one to create at run time. So, let’s introduce a factory. We’ll start with abstraction and then concrete factories for each type of book. Our factory will have only one method that returns an object which is abstracted by IBook interface:

Now, we need to update our BookStore class and equip it with factory property and allow a factory to be injected in the constructor.

What more you can notice in the code above Factory property is public therefore you can swap factories anytime you want.
And here’s how you can do that:

When an instance of BookStore is created in gets default factory injected through the constructor and then every time a book is about to be created the factory is replaced by another factory. The output of the above would be:

Notice that each book is of different type depending on which factory has been used to create the object.
So, that’s the basic use of factory method. To dig deeper I recommend the links below:

https://www.youtube.com/watch?v=EcFVTgRHJLM
https://stackoverflow.com/questions/69849/factory-pattern-when-to-use-factory-methods

I hope that this post (as the rest of my IT posts) is in any way useful for you. That is my last post IT series post for Get Noticed contest. But I will continue blogging and reporting my learning progress so if you’ve been hoping for that post about tabs please come back later. You’ll get it, promise!
Thanks, Michal

GetNoticed DEV#9: Demo is alive!

Good evening!
Demo application is alive! Here’s quick video of how it operates:



You can set your own items or click button to randomly create 10 items. Panels can be defined by user or you may allow the application to create unlimited number of panels with size set by user. So feel free to test it.
Next step would be to refactor the code. It is nasty, nasty I say. I will probably continue to develop the project after the contest is finished so the code will get cleaner. I don’t know if the app will get any bigger but for me it will be finished when I am not ashamed to show off with the code 🙂
Thanks for today, check the links below and good luck!

SheetMetalArranger on GitHub
Zip file with ClickOnce installer

 

GetNoticed DEV#8: Demo app mockup

Good evening!
Just to let you know that the project isn’t dead. As planned I’m trying to prepare a working demo of my app. I’ve been working on it since last weekend and I’m at the stage where I can present how the application will look:

Of course the mock-up is not all that I have achieved so far. All panels are fully working and backed up by view model. The most time consuming for me was to figure out how to work DataGrids and make tabs to be stored in a collection inside view model (maybe my next IT post will be about it). Now I need to make the view model communicate with ArrangerLibrary which will be my model. I will also need to add a class to ArrangerLibrary which will be responsible for generating PNGs. After that is done, code of the demo app will need to be cleaned and reorganised a bit for clarity.
It’s short and quick today but consider it as a far far away beacon that gives me hope that the goal is achievable.
Thanks, Michal

Nice tutorial how to work with tab control: https://www.youtube.com/watch?v=rFhmTccRUpQ
SheetMetalArranger on GitHub



GetNoticed IT#9: User control with data grid and observable collection

Good morning!
It’s been 10 days since my last post so the time is high! Today I’m going to write how to bind an observable collection of custom objects to a data grid in a WPF user control. Some time ago I wrote a post about basic use of user controls (see here) so this post you are reading right now can be considered as extension of the first one.

Objects in collection
Let’s start with preparing a class which objects will be stored in our collection. I won’t look for anything bright, I will just use something for my project: the class will store information about rectangles: height, width, margin and if a rectangle can be rotated. Additionally the class will have a property that returns area of a rectangle.

That’s the basic implementation of our ListedItem class. Now, to use it with observable collection in a way that it is bound to datagrid in UI and all values are automatically refreshed it is necessary to implement INotifyPropertyChanged. At the same time it would be wise to tweak our class a little bit: properties Height and Width cannot be smaller than 1. Also, when implementing INotifyPropertyChanged it is necessary to notify about Area property changed when any of Height or Width changes.

The last step would be to add a parameterless constructor that assigns all properties with default values.

View model
Our observable collection will be stored in our view model.

In the constructor of MainViewModel class we initialize the collection and add first item. And that’s for the purpose of this post is sufficient.

User control
Out user control will consist only of data grid inside a group box therefore the XAML is very simple.

What’s important in the code above are two things marked above: 1) assigning name to the user control (“this”), 2) defining data grid and its binding to dependency property Source.
Now, let’s move on to the code-behind the user control where we define dependency property.

We need to set the property of type ObservableCollection<ListedItem>, owner type ItemsList (as the name of our user control class) and name Source.

View
Now the last thing: combining all together in view. First of all we need to add namespace that contains our user control to namespaces used by the UI, create an instance of view model that is going to be used be the UI and set it as data context of top level grid.

To add our user control to the UI and bind observable collection for view model:

In this case binding mode is set as TwoWay because I want changes made by user in data grid to be reflected in collection in view model. But you have complete freedom here, that depends only on your needs.

So, basically that’s it. Before I finish few notes about customising the data grid.

Columns
The implementation above will generate columns in data grid according to properties exposed by elements in collection. But that is not the only way. you can set up your own names, for instance when you’re building multi-language app. To do that you need first set AutoGenerateColumns property of your data grid to false, and second define the columns manually. In our case that would be:

Note, that you need to be careful to use correct column type and to set binding correctly. In our case Area property is generated automatically therefore user must not be able to put anything in that column. To achieve that I had to set binding mode for this column to OneWay.

User edits
Depending on particular needs you may want to disable editing your data grid. There are certain properties that allows you to customise access to your data grid. To disable any edits you must set IsReadOnly to true, to make more precise customisation you can use set of CanUser properties which are pretty self-explanatory so there’s no point in describing them here.

Thanks for today, I hope that it’s gonna be somehow useful for you.
Regards, Michal

Sources:
https://msdn.microsoft.com/en-us/library/ee340710(v=vs.110).aspx
http://helion.pl/ksiazki/mvvm-i-xaml-w-visual-studio-2015-jacek-matulewski,xamlmv.htm