Showing posts with label WPF. Show all posts
Showing posts with label WPF. Show all posts

Tuesday, June 9, 2020

What is (was) XPS documents?

Time-saving tip
Part of this post was written long back and now I am completing as part of clearing my draft posts. This may not be relevant to the reader and may skip rest of this post.

What is XPS document

Simply "It is an XML-based (XAML-based) fixed-document format. Microsoft developed it and ECMA adopted it as standard 388. It is basically a zip file that we can simply open by changing the extension. This information can easily be obtained from Wikipedia.

This was Microsoft's answer to Adobe PDF. As always it is expected to kill PDF and long life. Unfortunately, the fate of WPF and XAML followed this as well. When the WPF declined this format also sidelined. In fact, it was not able to create much momentum in the first place. Microsoft included the XPS printer driver and all but fewer users tried it. As usual, there seems no official farewell ceremony from Microsoft's side similar to Silverlight and many other technologies.

Advantages

One advantage of XPS is the programmatic support in WPF to create an XPS document without any third party library that we need for PDF. But again a limited use case when we want to print the application screen as is. If its a report, we have a lot more options. With the advent of Electron, there seems no need to create WPF applications.

Disadvantages

The disadvantages were more. Mainly the adoption. All the platforms recognize PDF but less the XPS format. Another simple feature required for document format is to password protect it. XPS doesn't seem to have this basic support.

The advantages and disadvantages are not full. Feel free to add your thoughts in comments.

Tuesday, April 7, 2020

Contributing to one more open source GitHub project - tfstasksinoutlook

Background

When we are working from the office, we talk to people, show them what we did, help them solve their problem, etc,. That makes sure everybody knows that we are doing. Even if we are not religiously following the project management tools such as TFS. Even though there are no tasks planned in TFS for us in advance, people know we will be working on something. 
But that is different when we work from home. As of writing this post, the entire IT world working from home due to COVID-19. Instead of people asking us, are you free to do something? they may directly go to TFS and see what is our plan. If the TFS is not inline, we may get unplanned works and our planned works will be in trouble. 

If we are working as pure developers taking work items from TFS every morning, life is easy. We know or at least easy to plan what to be done. But it is different when we are up on the ladder. A lot of unplanned meetings may come into out way than actual technical works. Those will be in the outlook or a different planning tool than where our code and work items reside. If we don't get the full view of meetings and work, it is difficult to plan and making sure we show our status correctly.

Problem

In order to get the full view of the meetings and work items, we need to consolidate all in one place. One way is to create work items for each and every meeting and set the Start and Finish date and times respectively. There could be scenarios where clients move the meetings or cancel those. Need to sync up again

Another problem is that TFS doesn't have a calendar view to realize how we spend our day. Many companies don't care about each hour how we spend. But some need to know at the accuracy of 30 mins.
There is a team calendar plugin for Azure Dev Ops. But it may not be applicable in our company which is still with the on-premise TFS server. Not on-premise Azure DevOps Server Also, the team calendar is not designed to solve the problems we are dealing with there.

Approaches

Custom application

Develop a custom application to bring outlook calendar and TFS items and show those using a calendar control. Additional functionalities to create tasks and meetings can be added. This is a long route including hosting, authentication, etc...

Buy a product

There are some commercial outlook add-ins that merge TFS items into outlook calendar. But this category involves money which inturn involves approvals and all. All the features may not be there readily so we may need to spend time with the vendor to include the features we need also the options to customize. But it separates our problem of timekeeping to somewhere else and helps us to concentrate on our core business. People who can go this path should go here. 

Open-source / free Outlook add-in to bring TFS items

One last option is to search for any free or open-source outlook add-in. Free tools may not be having all the features we need. If there are just go for it. Open-source helps us to issue a pull request if we don't see the feature and would like to add one. 
Again there is no guarantee that all open-source projects in GitHub or anywhere else accept our PRs. Sometimes it may be more time consuming than buying a product or getting a feature into a free tool..

Solution

This may not be the solution for all. But at least it is working for me. I did some research in GitHub and figured out one Outlook add-in project named tfstasksinoutlook. I tried to use it and could see it is stable and has the basic features I need. The main attraction was it run, fetched TFS items and added to outlook calendar in the first attempt itself.

It is not that much documented. But easily figured out the process of what they are following. It is simple as creating an issue and issue a PR. Obvious in GitHub. Isn't it?

Tried the same path. It was staying idle for long time with the tools and technology versions of that time. I just upgraded the project to VS 2019 and the framework to 4.6 and issued a PR. To my surprise, it got approved within 1 day.

It needs some more features such as showing the start and finish dates, aligning the meeting based on the start and finish date of the work item, adding the TFS task from calendar items, etc...

PR to show "start and finish dates" is already given and got approved. Hopefully can give next PR to align the calendar item to start and finish date soon.

Benefits of open-source

Readers may stop here and just read the last line as they might have heard the benefits of open source. Below are some benefits I got by participating in this project.
  • Refreshed WPF skills. (Good as everybody forecasting a recession :))
  • Learned a different design for WPF applications. This project uses the System.Reactive than traditional MVVm.
  • Reading other's code and improving my coding skills.
  • Of course, a tool to view my TFS items and meetings in one place.
I believe the project got below benefits from my contributions
  • More issues logged
  • Little active after years with some features.
  • Upgraded tools and frameworks to a better shape. Not to the greatest, it is still .Net 4.6
  • A unit test project. Hopefully, people come after me will write unit tests
Thanks very much, Sergii for your nice open-sourced work.

Tuesday, September 20, 2016

IPC with SendMessage between WPF and WinForms apps

Communicating between processes is essential part of every big systems which we generally call as Inter Process Communication. If its large distributed systems the processes will be in different computers which we classify as servers and clients. Often we use http / http(s) based or other socket based communication mechanisms to do the job. In .Net world most of the people use WCF.

But in some cases there will be big systems running on same computer as separate processes and would like to communicate each other. We can use WCF here also with net.pipe binding. Since its same machine there are some more available options. Lets see what are those options. This post is about such an alternative which uses SendMessage API provided by Windows OS.

Clipboard

One of the dangerous forms of communication. Dangerous as user or any other application can copy new data to clipboard before our intended process reads data. But I have seen enterprise systems which uses this technique and working well for years.

EventLog

The sender can write to event log and the receiver subscribe to the event log entries to receive message. This will leave a trace of what has send back and forth between apps. But we should never use this for secure communication unless encrypted.

Standard In and Out of processes

One process can write to StdIn stream of another process and other can write to sender's StdId for two way communications. I have used this technique in one of my recent projects as it spawns processes frequently where publishing a unique WCF end endpoint was little difficult to achieve.

FileWatcher

Still many systems uses this technique. If there is a designated folder for messages and files are unique, it will work. in .Net works we can use FileSystemWatcher APIs to achieve the functionality.

SendMessage

Here we leverage the SendMessage windows API function to send a message to another process. That message then will be available to the message pump of receiving application. As we know the windows apps are running based on the messaging infrastructure. In simple words, the OS sends appropriate messages to apps about what is going on (eg:MouseClicked) with required contextual data and apps just process them. Its same for WPF as well though its hidden for normal apps. But there is a way to capture the message pump in WPF apps. 

A sample has been uploaded to github which shows how communication can be established between WinForms app and WPF app using SendMessage. Since the code is the true documentation, there is no more explanation required in this post.

https://github.com/joymon/Win32IPCDemo

Happy coding.

Tuesday, July 19, 2016

Communication between WPF Windows App & HTML Page hosted in WebBrowser control

Context

This can be considered as a continuation of one old post in this same blog. In that post we can see the technique to establish communication between HTML Page inside WebBrowser controls and and .Net application. In this post we are going to see the approach in detail. Code is available for download and is self explanatory.

Technical details


  • For WPF to JS communication
    • WebBrowser control has a method called InvokeScript.
    • This can be used to invoke any JavaScript function present in the rendered web page and pass parameters.
  • For Web page/JS to WPF .Net communication
    • WebBrowser has a property called ObjectForScripting which will be available in JS as window.external
    • If we set an object to ObjectForScripting property, that .Net object will be available in JS and from JS we can call any method on that object which will in turn call the .Net code.

What’s not done

This just proves the technique. Performance testing is not part of this.

Source code

  • The HTML page is inside the WPF.
  • WebBrowser loads the HTML page by using pack: uri syntax.
  • WebBrowser's ObjectForScripting Object is set when the window loads
  • A class which is comvisible is used for the above property
  • From JavaScript the SetAValue() is called to pass data from JS to WPF
  • For WPF to JS myWebOC.InvokeScript() is invoked
  • In JS the data is received in the setSomeText() function.
Download from the below url.