Templot Club Archive 2007-2020                            < back - search archive  browse archive images

---

4. I have created a new top menu (we haven't had one of those for ages) called utils. I have moved there the utility functions from the tools menu -- the ruler, dummy vehicle, metric calculator, etc. In a future update I want to split the spacing-ring and dummy vehicle into separate functions.

This leaves the tools menu shortened to a more sensible length, and logically concerned only with track design.

---

Martin.

Good that you have shortened the tools menu but should the adjacent track centres menu option still be in it ? Most of the other tool actually create something which is what a tool is for. The track centres doesn't, it just changes a setting for the next tool to use.

I have not noticed any improvement  when I use the bounding rectangle

madscientist wrote:

I have not noticed any improvement  when I use the bounding rectangle

Hi Dave,

Don't forget you must draw the rectangle AND switch on its use for limiting template drawing (SHIFT+END does that). It is also used for other purposes (image file exports).

You will see a difference only if

a. it is a large track plan, say more than 50 background templates, some quite long, and

b. you zoom out further than the rectangle. If you zoom inside the rectangle you won't see any difference from using the rectangle, it should be faster than before regardless. But only for large track plans.

If you have a high-end fast system, the improvement may be only minor.

It is definitely making a difference here.

cheers,

Martin.

Hi Philip,

Is that happening all the time? Or only when you click on a background template?

Did the same happen before 218d, or is it new in 218d?

Does Parallels provide any controls to change the size of the container for Windows programs?

Thanks for posting it.

regards,

Martin.

Hi Dave,

If you are using Parallels, are you seeing the same problem as Philip?

regards,

Martin.

Hi Philip,

I'm waiting for Dave (or anyone else) to report on whether he is seeing anything similar in Parallels.

I don't think this is related to any of the changes in 218d. I've been doing some measuring on your screenshot, and it seems that the background bitmap is stuck at 1624 x 1140 pixels. Given that it gets set to the full screen size during start-up, that's a bit of a mystery, unless it is possible to change the Windows screen size in Parallels while a program is running?

By screen size I don't mean the size of the trackpad window, I mean the full area of the monitor and the current screen resolution setting. On a normal Windows desktop computer that wouldn't get changed very often, and certainly not in the middle of using some software. But it's possible a virtual machine may allow it to be dragged to a new size at any time. I just don't know.

I'm trying very hard not to get forced into a position where I have to buy a Mac computer just to understand what's going on. Every time problems are reported I find it very difficult to follow what is being said.

You don't want to hear what I'm going to say next. But a few years ago I had a system which produced results very similar to your screenshot, and that turned out to be a faulty graphics card.

I'm hoping that this will prove to have been a temporary glitch, and that the next time you do a restart it will come right. Try to do that with nothing else running, so that we are not looking at problems caused by a shortage of memory.

cheers,

Martin.

Thanks Dave.

But what's the answer to the question?

Does Parallels always use the full area of the monitor? Or can you have Parallels running in one part of the screen and normal Mac operations on another part?

And if so, can you change the size of the Parallels section while a Windows program is running within it?

And if you can, do scrollbars then appear if going smaller? What happens in the blank area if going larger?

regards,

Martin.

Its decided in exactly the same way as the app decides the initial screen size in Windows , Parallels does not provide a Window " container "

Windowed desktop, IN that case the user by dragging the windows essentially sets a " variable " screen resolution

madscientist wrote:

Its decided in exactly the same way as the app decides the initial screen size in Windows , Parallels does not provide a Window " container "

But in that case there is no difference between full screen and coherance?

An app doesn't decide the screen size in Windows. It gets told by Windows the size of monitor screen.

This is getting silly. In Parallels what is the result of a Windows app setting a variable to Screen.Width?

And is it capable of changing while the app is running?

Because something changed in Philip's screenshot.

regards,

Martin.

When I release the mouse button, the relevant Windows repaint message causes Templot to redraw and properly fill the new window ( in about 1 sec)

Is this what Philip is seeing

madscientist wrote:

Windowed desktop, IN that case the user by dragging the windows essentially sets a " variable " screen resolution

We got there at last!

That's completely different to a Windows computer, isn't it?

Now finally. What happens if you launch Templot while using a small container? And then make the container larger?

regards,

Martin.

Yes there is an issue, it looks like Templot does not rescale properly on the resolution being changed and the window being made bigger .in essence the starting window size is maintained and in effect a cropped template is shown even when the desktop is resized 

This behaviour is not evident in other windows apps, I just tested SCARM

madscientist wrote:

Yes there is an issue, it looks like Templot does not rescale properly on the resolution being changed and the window being made bigger .in essence the starting window size is maintained and in effect a cropped template is shown even when the desktop is resized 

This behaviour is not evident in other windows apps, I just tested SCARM

BINGO.

I knew that had to be the case from Philip's screenshot. He, or his system, enlarged the container after launching Templot.

That's not something that Templot supports or will ever support. It makes my head hurt just thinking about what it would mean. It's like unplugging a 17" monitor and plugging in a 29" monitor instead, right in the middle of doing some timber shoving.

If other apps don't show the same effect, it is because they are not using a backdrop bitmap.

Many thanks for your help.

cheers,

Martin.

Its actually a requirement that Windows apps support dynamic resolutions

madscientist wrote:

Its actually a requirement that Windows apps support dynamic resolutions

Who says so? Not here it isn't.

Templot creates its own screen-sized work area at start-up. The consequence of changing the size of that while running just don't bear thinking about. The only way would be to dump the data to a file, restart Templot, and then reload the file.

I'm not going there. I have enough other stuff to do.

cheers,

Martin.

Templot creates its own screen-sized work area at start-up. The consequence of changing the size of that while running just don't bear thinking about.

Martin Wynne wrote:

Templot creates its own screen-sized work area at start-up. The consequence of changing the size of that while running just don't bear thinking about.

Hi Dave,

I have been taking a closer look at this, and I believe it is not such a major task as I first feared.

However, I'm not going to do it because I have no way of testing it. I have no means to plug in a different-sized monitor while Templot is running. I suspect that the number of users who would want to do such a thing is so few that it would not be worth the effort anyway.

cheers,

Martin.

Tonight I've moved from cinema display to laptop screen and have no problem with ghosting. I have not been able to replicate it, even by making the Parallels window smaller then bigger.

you could just capture The relevant WM message and just display a dialog, saying Templot doesn't support dynamic resolution changes !

Hi Martin,

The simple solution is to supply a can of DDT with every copy of Templot.

Regards,

Andy

DDT = Don't Do That

DDT = Dichlorodiphenyltrichloroethane

Rob Manchester wrote:

DDT = Dichlorodiphenyltrichloroethane

My dad was a great fan of the stuff. I'm not quite sure why I'm still here.

madscientist wrote:

you could just capture The relevant WM message and just display a dialog, saying Templot doesn't support dynamic resolution changes !

Hi Dave,

To do that, I first need to generate such a WM message to test it, and I have no means of doing that.

If I simply change the monitor resolution while Templot is running, I get the expected message from Windows saying that to apply the changes I must restart Windows.

In 40 years working on Templot it has never occurred to me to try to do such a thing. Not for the first time, I get the feeling I'm on a different planet from everyone else.

cheers,

Martin.

Rob Manchester wrote:

DDT = Dichlorodiphenyltrichloroethane

My dad was a great fan of the stuff. I'm not quite sure why I'm still here.

Plug in a digital projector

madscientist wrote:

Plug in a digital projector

This is getting a bit silly. The number of users who seriously want to do this without restarting Templot must be vanishingly small.

cheers,

Martin.