[dforrest]

Can the Activity Events window be made larger or, even better, be made adjustable in size?

[steamer_ctn]

The ability to make the activity pop-up window bigger in some instances, such as were there is a relatively large amount of text, has also been suggested through the uktrainsim site.

Is this a possibility, perhaps as a switchable option, and easy to implement?

Thanks

[James Ross]

steamer_ctn, on 03 February 2016 - 02:28 AM, said:

The ability to make the activity pop-up window bigger in some instances, such as were there is a relatively large amount of text, has also been suggested through the uktrainsim site.

Is this a possibility, perhaps as a switchable option, and easy to implement?

It's probably possible to make it resize itself to fit the text, as long as there is a limit, but don't bother with an options - just do it. :)

(When the UI is redone in https://blueprints.l...pec/gui-refresh it will definitely be fixed.)

[steamer_ctn]

Hi James,

Thanks for the reply.

When is the UI programmed to be done? As at the moment, I don't know how to set up the window resizing, and I would need to try and work out the code?

Thanks

[James Ross]

steamer_ctn, on 03 February 2016 - 12:41 PM, said:

When is the UI programmed to be done? As at the moment, I don't know how to set up the window resizing, and I would need to try and work out the code?

The new UI work is stalled at the moment, so I wouldn't worry about it.

As for the resizing, you just need to call "SizeTo(int width, int height)" once you've figured out the right size. I suggest that you do this at the end of the "ActivityWindow.Layout" function, but taking care not to get in to a loop - calling "SizeTo" will trigger "Layout" again, but only if the new size is different. The calculation will involve the "scrollbox" and "Message" variables in some way, maybe just as simply as figuring out which is taller and by how much. You can get the current size from "Location".

[steamer_ctn]

Hi James,

Thanks for the feedback.

James Ross, on 04 February 2016 - 11:29 AM, said:

The new UI work is stalled at the moment, so I wouldn't worry about it.

Ok, I will not hold my breath waiting on it.

I have now had time to play with the code in the ActivityWindow.cs file, and found the following.

James Ross, on 04 February 2016 - 11:29 AM, said:

As for the resizing, you just need to call "SizeTo(int width, int height)" once you've figured out the right size. I suggest that you do this at the end of the "ActivityWindow.Layout" function, but taking care not to get in to a loop - calling "SizeTo" will trigger "Layout" again, but only if the new size is different.

Firstly, I had a play with the SizeTo statement with fixed values, and you are correct that it does resize the window.

For comparison, I have attached some screenshots. The original window is attached as "orig.jpg". I think that its size is "fixed" at 383 x 158 (according to the "Location" information).

I set the SizeTo statement to 766 x 316, and got the box shown in "sizeto.jpg". Which didn't appear to preserve the same proportions as the original by leaving a big gap at the bottom of the window.

Upon investigation, it appears that the pop up window is made up of a number of boxes, including the outer darker box, and the text box.

I then added scaling factors to code lines 42 & 51 as below.

: base(owner, Window.DecorationSize.X + owner.TextFontDefault.Height * 2 * 25, Window.DecorationSize.Y + owner.TextFontDefault.Height * 2* 8 + ControlLayout.SeparatorSize * 2, Viewer.Catalog.GetString("Activity Events"))

var hbox = vbox.AddLayoutHorizontal(Owner.TextFontDefault.Height * 2 * 6);

The result is shown in "scaled.jpg". This appears to be a more pleasing effect for boxes with larger volumes of text.

As each activity window will have different amounts of text in them, trying to scale the box off the text amount (I am still not certain how to do this) will probably result in various size pop boxes appearing throughout the activity, which may not be a pleasant effect, depending upon the parts of the screen that they cover.

My personal preference would be:
i) to use a scaling factor
ii) set it in the activity (act) file so that an activity builder can control how big or small the boxes are displayed.

As I am still uncertain about how to size the boxes off the text, if you feel that it can and should be done on that basis, can you provide some additional clues about how to do it?

Thanks

Attached thumbnail(s)

• 
• 
• 

[James Ross]

steamer_ctn, on 04 February 2016 - 08:36 PM, said:

I set the SizeTo statement to 766 x 316, and got the box shown in "sizeto.jpg". Which didn't appear to preserve the same proportions as the original by leaving a big gap at the bottom of the window.

Looks like the code lays it out at a fixed height instead of flexing it. This should be reasonably easy to fix by changing the following code:

                var hbox = vbox.AddLayoutHorizontal(Owner.TextFontDefault.Height * 6);

To something like:

                var hbox = vbox.AddLayoutHorizontal(vbox.RemainingHeight - (ControlLayout.SeparatorSize + vbox.TextHeight) * 2);

I also recommend that the resizing only happens in the vertical dimension, otherwise it will indeed look very odd throughout an activity.

Do NOT let this be set in the activity file; any kind of information like this is very sensitive to changes in the interface (both visual and structural) and would likely become obsolete or need replacement with another, different value.

[steamer_ctn]

Hi James,

Thanks for the feedback.

James Ross, on 05 February 2016 - 10:12 AM, said:

                var hbox = vbox.AddLayoutHorizontal(vbox.RemainingHeight - (ControlLayout.SeparatorSize + vbox.TextHeight) * 2);

I am sorry, but I still need some clarification.

Is it simply a case of replacing the appropriate line with the above code, or are there some other calculations that need to also be done?

I have inserted the above line, and the box appears to be the same size as the default one.

Thanks

[James Ross]

steamer_ctn, on 05 February 2016 - 10:56 PM, said:

Is it simply a case of replacing the appropriate line with the above code, or are there some other calculations that need to also be done?

I have inserted the above line, and the box appears to be the same size as the default one.

Yes, replace the existing line with mine. My line wasn't tested so might need some tweaking, that's all.

If the window is kept the same size as it is now, my change won't make any difference - however, if you make the window bigger with a "SizeTo" then it should make things lay out much better than they currently do.

[steamer_ctn]

Hi James,

James Ross, on 06 February 2016 - 01:36 PM, said:

Yes, replace the existing line with mine. My line wasn't tested so might need some tweaking, that's all.

If the window is kept the same size as it is now, my change won't make any difference - however, if you make the window bigger with a "SizeTo" then it should make things lay out much better than they currently do.

Thanks for the further feedback.

The window now appears to resize correctly.

The final piece of the puzzle is how to trigger a resize of the popup window?

Can you see where the amount of text to be displayed in the window can be measured, and then compared to trigger the SizeTo statement if it is over a certain amount?

Thanks

[James Ross]

steamer_ctn, on 07 February 2016 - 01:00 PM, said:

The final piece of the puzzle is how to trigger a resize of the popup window?

Can you see where the amount of text to be displayed in the window can be measured, and then compared to trigger the SizeTo statement if it is over a certain amount?

I believe this should be done inside "Layout"; probably right at the end. You should be able to compare the height of the Scrollbox and the TextFlow, although I'm not 100% sure.

[steamer_ctn]

James Ross, on 10 February 2016 - 11:42 AM, said:

I believe this should be done inside "Layout"; probably right at the end. You should be able to compare the height of the Scrollbox and the TextFlow, although I'm not 100% sure.

It appears that the code that creates the window size runs early in the process, before the text for each window is analysed. It also appears to only run once.

Once the text is analysed, the text is then fitted into the "pre-defined" window size already established.

So therefore I don't think that the text size can be used to influence the box size.

I will send a PM with some more detail.

[James Ross]

steamer_ctn, on 10 February 2016 - 02:25 PM, said:

It appears that the code that creates the window size runs early in the process, before the text for each window is analysed. It also appears to only run once.

Once the text is analysed, the text is then fitted into the "pre-defined" window size already established.

So therefore I don't think that the text size can be used to influence the box size.

The process is certainly outside-inwards, but there's nothing stopping the window changing its size after creation. I've just tested that and it works fine calling "SizeTo" inside "Layout". The only bit that may be tricky here is when the text is laid out. If that is after "Layout" has finished, we'll need to add an event or override some other code, but it should not overall be troublesome to do.

I'll have a look later this week.

[James Ross]

James Ross, on 10 February 2016 - 03:14 PM, said:

I'll have a look later this week.

I was wrong about where this needed to happen, because the text is added separately from the layout and I also had to make layout not reset the various text boxes/labels, but it's still a pretty simple change. I made the dialog 1.6x wider and taller by default and will resize up to 2x taller (than the new size) if the text needs it. I've attacged the patch if you want to try it - I think it works pretty well.

Here's how it looks in your beta tutorial activity:
https://james-ross.co.uk/temp/Open%20Rails%202016-02-13%2001-30-12.png

I do not want to go larger than this, so it's up to you if you keep the amount of text you currently have (which generally overflows by ~25%) or try and fit it in.

Attached File(s)

•  activity-events-window-1.patch.txt (6.99K)
  Number of downloads: 161

[steamer_ctn]

Hi James,

James Ross, on 13 February 2016 - 05:35 AM, said:

I was wrong about where this needed to happen, because the text is added separately from the layout and I also had to make layout not reset the various text boxes/labels, but it's still a pretty simple change. I made the dialog 1.6x wider and taller by default and will resize up to 2x taller (than the new size) if the text needs it. I've attacged the patch if you want to try it - I think it works pretty well.

Thanks for that.

I have tried to apply your patch (against #3439), but the following lines of code are bringing up errors in my development version of OR.

        	var originalMessage = Message?.Text;
        	var originalResumeLabel = ResumeLabel?.Text;
        	var originalCloseLabel = CloseLabel?.Text;
        	var originalQuitLabel = QuitLabel?.Text;
        	var originalEventNameLabel = EventNameLabel?.Text;
        	var originalStatusLabel = StatusLabel?.Text;
        	var originalStatusLabelColor = StatusLabel?.Color;

It is indicating a syntax error, ":" expected.

James Ross, on 13 February 2016 - 05:35 AM, said:

Here's how it looks in your beta tutorial activity:

I do not want to go larger than this, so it's up to you if you keep the amount of text you currently have (which generally overflows by ~25%) or try and fit it in.

My personal preference would be to have a wider and shorter window, so that the amount of screen taken up by the window is kept to a reasonable balance (see the attached screenshot as an alternative example). Perhaps the window could be made slightly wider then the screenshot, such that the first paragraph is only on three lines.

I am not overly concerned that some text scrolling is required, as I feel that the larger window makes the text in the window is "more readable".

Given that the patch is working in your OR development version, do you wish to apply the patch?

Thanks