Monthly Archives: October 2018

C++, Daily Blog, General Technical, Projects, Thoughts, Topics

Automation for PDF Viewing

Leave a comment

I’ve wanted to automate view management for PDF documents for some time. It would provide a way to make locating the document I want and getting content up on the screen amid a mass of technical documentation much easier (and with the cryptic names that many companies use for their pdf files that can be a big deal).

Ideally I’d like to access the viewer over something like a DCOM automation link with full control over the view state and other particulars. In a pinch, I’d settle for process control, cross process window size and location management and some command line arguments to force the view mode and initial page view.

Here are some pages that might be helpful with this (still reading things but trying to keep a record here).

Another approach would be to find a PDF renderer that can be run inside a C# or C++ process. Looking there as well… Suspecting there may very well be a project or two on GitHub.

Topics, Win32

Win32 Multiple Monitors

Leave a comment

Spent some time over the weekend looking at APIs in windows that give access to the monitor configuration of the system that code is running on.

I tend to run on systems with several monitors (usually as many as is practical). Ideally, I’d like to create tools that can use the available display real-estate in helpful ways.

The main API involved is EnumDisplayMonitors which will invoke your provided callback function with the HMONITOR for each monitor that is recognized by the system. Calling GetMonitorInfoW can then provide some of the details of each display in a MONITORINFOEX structure.

One oddity in all of this is that a monitor with a scaling factor applied (my 4K monitor is set to 150% scale factor for usability reasons) returns the post-scaling size with a gap in the coordinate system that reflects the ‘missing’ pixels. In my case the small monitor I use to keep an eye on the router is logically far to the right of the left hand edge of the big monitor.

There is a supplementary API call GetScaleFactorForMonitor which returns a DEVICE_SCALE_FACTOR indicating the current scale factor for a given monitor. This is a little bit strange on my system as the big monitor appears to be set for 150% scaling but the API call shows 140% scaling. The size numbers match what I’d expect for 150% so something must be a bit off here…

Interesting API to look into GetDpiForMonitor and MONITOR_DPI_TYPE.

Looks as if the SetProcessDpiAwareness API (with PROCESS_DPI_AWARENESS and WM_DPICHANGED) may have a part in all of this as well…deciding whether the process gets presented DPI aware or virtualized display metrics.

Curious translation in GetPhysicalMonitorsFromHMONITOR  could use a bit of a look.

I need to read more of the DPI aware and multi-monitor articles before I’m done here. I also want a better idea of how this functionality interacts with WPF user interfaces as I’m likely to build the upper layers that way.

This certainly gets more complicated with display scaling and DPI calculations in the mix.

Some more relevant articles (I haven’t read these all in detail yet):

Java, Topics

Java Tasks don’t do Lambdas

Leave a comment

I was spinning a thread recently and it was pointed out to me that the environment I was working in at the time used Task (JavaFX code) for such things. My thread was being created with a Lambda expression as the action to be performed. It surprised me when I could not directly translate that to a Task.

After a bit of research I found this post discussing why that is the case (as a side-effect of the fact that Task is an abstract class). As with so many things in Java where the choice is to accept less expressive and longer winded approaches to limit language level complexity, I’m not sure I agree with the choice, but it is what it is at this point.

Adding in the anonymous local class framing isn’t a big deal and that’s clearly the way to go for this item. 

Embedded, Topics

Xilinx Versal looks interesting…

Leave a comment

…for designs that have the budget and requirements to need this amount of capability. 

Just saw a web article on the family of parts. Programmable logic, ARM cores, DSP and machine learning resources along with high speed digital logic. Very interesting sort of parts…potentially allow for highly reconfigurable logic with lots of fast local resources to drive things. I’d love to get my hands on one to experiment with when they ship, but I expect they’ll  be far too pricey for my limited budget…

White paper here. Article from The Register here.

Also interesting items here and here related to ARM cortex M.

Embedded, Projects, Sandbox

Taking a quick look at Mbed

Leave a comment

A friend at work pointed me at Mbed devices for real-time end of line work. I’ve been involved in work that used 68hc11 processors for that sort of thing (getting very long in the tooth) and I’ve looked at using AVR parts (cheap, dip packages and decently capable). PIC controllers also seem to show up frequently (but the small look I’ve taken at the PIC architectures doesn’t make me happy).

These are ARM Cortex-M0 devices with what initially looks like pretty decent support. As an outbound, real-time controller and a back-end in something like an RPi (for home stuff) these might be a better solution than the AVR chips.

I’ve had good results from building systems with the ‘quick twitch’ responses pared down to the smallest size reasonable and baked into small controllers and keeping the higher level control (that doesn’t have the real-time response requirements) back on a linux or windows based system. This keeps the complexity in a location where powerful development tools and more capable processors reside and makes development much simpler.

I’ve been looking at CAN as an intermediate communications bus for this sort of work as well. The SPI and I2C options work well for tightly coupled peripherals in the same voltage/signalling family but don’t extend well.

Ethernet is wonderful for larger scale coordination between components that are running relatively complete operating systems.

CAN splits the difference with a defined physical layer running differential signalling that provides common mode noise resistance and (probabaly…haven’t looked in detail) avoids ground reference issues. It is still low level enough to code directly to (unlike TCP where the stack gets a bit involved to do things right). It supports quite a few devices on a single connection and has a decent access arbitration mechanism.

I haven’t bought any parts to try playing with this yet, but it seems promising.