Tools for Cross Platform Development

Share icon

Hi,

I am working on a cross platform project that has a fairly involved GUI. Due to the nature of the display differences I need to enter position and size corrections to the control objects in window macro. To do the is I have some code in the window macro that reads the screen resolution and compares it to the 72 dpi default on the Mac. I then multiply the ratio in the position and size fields.

Variable PC = ScreenResolution/72 // correct for screen resolution
GroupBox DefaultRadii,pos={772.00*PC,130.00*PC},size={94.00*PC,181.00*PC},title="Default\rRadii"

When I tweak the layout with the tools and add new elements, I run into a bit of problem/issue, when I update the window macro it inserts the current values with just the number removing the correction term "*PC".

I then have to go back and modify all the fields again.

Is there an easier/automatic way to do this?

Can we add this to the wish list?

Andy
hegedus wrote:
When I tweak the layout with the tools and add new elements, I run into a bit of problem/issue, when I update the window macro it inserts the current values with just the number removing the correction term "*PC".


I am not quite sure I understand this sentence, but as far as I get it (i.e. graphically adding/removing/adjusting position of GUI elements onto the panel), I think there is no way of dealing with this apart from doing the element positioning and size by hand.

best,
_sk

July 11, 2017 at 01:45 am - Permalink

I think that Andy meant that after manually moving controls and saving a panel recreation macro to capture the new control positions, the code generated by the recreation macro only uses absolute numeric values.

I don't imagine there's an easy way around this. I usually only work on my code... tweak the code, compile, run, see how the control layout looks & loop back to the beginning.

July 11, 2017 at 07:59 am - Permalink

You can either use window recreation macros or create the panels manually in functions. I used to do the latter but nowadays prefer window recreation macros.

I don't really understand why your GUI controls are not layouted the same on Mac and Windows. During the transition period from IP6 to IP7 I had duplicated some window recreation macros to adapt them to the igor version. If nothing else holds you can use that approach as well.

July 11, 2017 at 08:19 am - Permalink

Attached are some examples of the issue I am running into.

The client is running on a Windows based server and I am developing on a MacBook Pro. I have no access to their machine so I do not know the details of the screen. Often the client remotely logs into via remote desktop.

We are both using IP7. If I include code to test for the screen resolution and adjust the position and sizes accordingly then the window with controls looks as I intend. If I modify the window to add new controls for example and choose update macro then the code with the scaling parameters is lost and is replaced by absolute numbers derived from my Mac screen.

In the manual it talks about control panel issues between the platforms and the placement of controls. The display is a technically a graph and not a control panel. Are the placement of controls handled differently with a panel as compared to a graph. I notice in the manual there is discussion of the use of the setsetigoroption PanelResolution = . Does this apply to graphs?

Andy
Windows.png (795.68 KB) Mac.png (1.2 MB)

July 11, 2017 at 09:01 am - Permalink

hegedus wrote:
... If I modify the window to add new controls for example and choose update macro then the code with the scaling parameters is lost and is replaced by absolute numbers derived from my Mac screen.


In my experience, this is standard behavior.

hegedus wrote:
In the manual it talks about control panel issues between the platforms and the placement of controls. The display is a technically a graph and not a control panel. Are the placement of controls handled differently with a panel as compared to a graph.


In my experience on Igor6, you must account for screenresolution in either case.

hegedus wrote:
I notice in the manual there is discussion of the use of the setsetigoroption PanelResolution = . Does this apply to graphs?


I don't know (this is new to me). But ... I notice the caveats ... PanelResolution is NOT remembered across invocations of Igor and it only applies to the panel currently being generated.

I suspect the best answer, as you are doing your development, is to generate the panel by code, not by window recreation. Include a button to Refresh Panel. It would kill the panel and rerun the code needed to create it. I think the only safe situation to use window recreations will be the end case after you have locked in the control positions forever and always. Even then, under Igor6, I'd not be sure that a recreation created on one screen resolution will translate identically to another. Reading between the lines however, assuring clean translations of panels is what PanelResolution in Igor7 is supposed to solve.

--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH

July 11, 2017 at 01:41 pm - Permalink

Is the block of control to the right of the graph a bunch of controls dropped into a graph? If so, then you aren't using the recommended technique. We would suggest creating a control panel subwindow occupying the space to the right of the image. Put the controls into the panel subwindow, and you shouldn't have positioning problems like that.

John Weeks
WaveMetrics, Inc.
support@wavemetrics.com

July 11, 2017 at 03:56 pm - Permalink