Did someone change the dockscreen use of desc=""?

[Periculi]

When I use panes in dockscreens and place the desc="Text to display as description on the right above the options" the text isn't showing up except for the default pane desc.

Did something change about how to use the desc value for a pane in 099?

(I don't see a mention of this anywhere grumble)

It only showed up when I used scrSetDesc in the initialize of Default pane. I had been seeing all the desc as per usual when the default pane didn't make use of a scrSetDesc to alter the desc text. Once it is used, all the panes now show only the new text set by (scrSetDesc gScreen [var]).

Why would this be changed? In 098 I never had this happen to me.

[george moromisato]

Nothing has changed. And there are still panes and dock screens that use desc="..." and they are working as far as I know.

Can you include an extensions that reproduces the problem?

[Periculi]

This has the buggy description for me: Nav Mod

(psst- the mod works, if anyone wants to check it out it just needs the star system description info added and a few minor adjustments before release.)


I think there may be a problem coming up due to how I am handling switching panes and the lists shown.

dsNavigation is the main dockscreen where the buggy desc is happening.

You can access it in game using the test ship included.

The dockscreen uses a LOT of panes. The default pane initialize handles all the pane changes.

When you switch from default (Current System Info View) to another pane such as Network Overview, what happens is a navState variable is set. Then the action loads the screen again- so the default initialize catches the state change and switches to the requested pane.

I have never tried this many panes before but I have done a state change system like this with good results, and I think what may be happening is that the scrSetDesc is getting carried over to the new pane somehow.

I may just have to add an initialize to the panes to set the desc to what I want to be sure that the desc isn't carried over from when default initializes and flips to a new pane.

I am wonderign if you are going to tell me to do this with more dockscreens, and it might actually be a good idea, but I wanted to see how complex of a pane system I could create- this single dockscreen has 3 modes and each mode has a variety of viewing states all controlled from the initialize in the default pane.

If you could George, take a look at the code and tell me what you think- I am interested in creating good code- and was also thinking that something like this could be used to handle more complex mission interaction.

I know I also should probably use something like gScreen, but I don't recall seeing gPane in use in many dockscreens. The other consideration I have is that the list changes it's state with the panes- so the same customPicker screen is able to get a variety of lists presented by using the state variables.

I used the same system in 098 and never ran across this desc behavior, which is why I was wondering if you changed how it was handled.

[george moromisato]

This is a really cool mod! You're definitely pushing the envelope of mod-development, but I expect that from you!

The only thing I saw that was a little funky was that you are calling (scrShowPane...) from inside the <Default> pane's <Initialize> code.

If you want a screen to show a specific pane (instead of <Default>) then you should add an <InitialPane> element for the screen and return the name of the pane that you want to show. Look at KorolovShipping.xml, line 1377 or so.

Let me know if that makes sense.

[Periculi]

This is a really cool mod! You're definitely pushing the envelope of mod-development, but I expect that from you!

Wow, thanks! I appreciate the feedback and the compliment.

If you want a screen to show a specific pane (instead of <Default>) then you should add an <InitialPane> element for the screen and return the name of the pane that you want to show. Look at KorolovShipping.xml, line 1377 or so.

I guess I never understood the <InitialPane> usage, haven't really ever tried it before. Can the Initial pane handle the same code? I guess it would be the initial pane each time you enter the screen as I have it set up, and I am assuming that the <InitialPane> can handle the same state check- I hadn't really ever looked into it, just thought I would use the initialize and see what happened. I will try the <InitialPane> and see if that clears up any strange behavior. Thanks for the tip.

[george moromisato]

I guess I never understood the <InitialPane> usage, haven't really ever tried it before. Can the Initial pane handle the same code? I guess it would be the initial pane each time you enter the screen as I have it set up, and I am assuming that the <InitialPane> can handle the same state check- I hadn't really ever looked into it, just thought I would use the initialize and see what happened. I will try the <InitialPane> and see if that clears up any strange behavior. Thanks for the tip.

Yes, <InitialPane> can handle the same kind of code. The difference is that you need to return the name of the pane that you want to show. [Don't call (scrSetPane)]

<Initialize> is called *after* a pane has already been selected. Calling (scrSetPane) inside <Initialize> messes things up (like, apparently, the desc)

[Periculi]

That works great! It was an easy fix, too.

Your code just switches without any setq or anything, right?

You have it
(eq something somethingelse)
"paneName"

I used a (setq setPane "pane name") and it worked too.

I bet I could have just set the name of the pane as the navState-
then retrieve it there in InitialPane, with a nil catcher to set first run
<InitialPane>
(block (pane)
(setq pane (objGetData gSource "navState"))
(if (not pane)
(setq pane "Default")
)
pane
)
</InitialPane>

[Periculi]

Seems like I jumped the gun on that.

Now the panes switch when any item on the list is clicked. So you go to select an option and the dockscreen changes back to the default menu- the list remains, but the options jump to default- which makes changing the log entries, flagging a system, gatewalking, or any of the sub panes impossible to use.

Why is the screen updating to the default pane whenever a list item is clicked? I liked it better the other way- mostly because I think I can fix it. I don't have a clue how to fix this new buggy action.

Is this a problem with the customPicker? The list stays correct, the title of the screen stays correct- if it was reloading the dockscreen the function that changes the name and the list would be triggered. But it isn't- it just jumps back to the default pane's menu options on the right side and everything else about the pane stays the same. So I end up with the menu from the default pane on every pane I try to choose something in.


dbgOutput results show that every time a menu item is clicked the screen wants to return to the default pane. Even though the navState results in the correct list and the name for the screen stays the same, the pane is automatically switched to default when an item is clicked or the list cursor is moved. How can this be resolved- short of making a dockscreen for all 25+ sections of the nav computer. That just doesn't seem very efficient.

Why is interacting with the list flipping to the default pane at all?

I suppose it needs to in order to update the screen or something to move the list- but because it does, <InitialPane is worthless in this application because it is outside of the panes so it doesn't get run again.

This really a bummer, this was working great for me in 098d. I had no problems setting a multi-state list/pane changer up and getting exactly the results I want and now it's looking more like it's not going to work at all in 099. Either the screen desc gets messed up (and whatever other problems may occur in using default's init), or the panes get totally confused because <InitialPane> doesn't get called on an update.

[Periculi]

8) If I move the (scrSetDesc) in the default pane above the code that switches that pane everything works fine.

However, initialize (scrSetDesc) in panes other than default can't be used even though the initialize does trigger (dbgOutput at least).

I did fix the desc problem, and got the screens to show what I wanted. I also think I could actually use the default initialize to set the desc of the other panes as well, based on navState.

<InitialPane> won't work with the lists, and I haven't seen any problem other than the desc bug from doing it with default pane's initialize.

scrShowPane in default is needed to force the panes to display properly when using the list.

I tested using the navState switch in default to change the desc there, and it worked well- panes can have screen desc set from default's initialize. Which means that the whole pane set can be controlled from default's init and the sub-panes used to alter the options for the list being viewed.

What other errors could it be causing? I don't get any crashes, and if it is going to work then I am going to do it this way. Otherwise I need more than 25 independent dockscreens with a bunch of work to get them linked together properly, and this pane system is working well as far as I can tell now that I moved the single scrSetDesc line.

What do you think?

[george moromisato]

Well, I can see a couple of options, but I don't totally know your requirements. Let me run some things by you:

1. I could make it so that <InitialPane> is called after every change of the list (instead of always going to <Default>). I think that would make more sense.

2. If you are controlling the pane from <Default> why not just dynamically set the desc and the actions from <Initialize>? Then you won't need any other panes! You could do everything from the <Default> pane.

For example, you can call (scrShowAction gScreen 0 Nil) to hide the first action in the pane. In <Initialize> you can hide all the actions that you don't need.

[Periculi]

For example, you can call (scrShowAction gScreen 0 Nil) to hide the first action in the pane. In <Initialize> you can hide all the actions that you don't need.

Is scrShowAction new? I wish I had run across that earlier! I had thought to make a one pane version before, but thought that all that could be done to change the actions was scrEnableAction, which just greys out the action rather than removing it from the menu. I decided to try changing pane states in order to create more menu options in the same dockscreen frame.

I will have to try this out.

1. I could make it so that <InitialPane> is called after every change of the list (instead of always going to <Default>). I think that would make more sense.

If you want, but I think your other answers might be more doable in the short term and make it just as effective.

If I could do it all from one pane, that would actually be preferable.

It works now, with no changes. So no need to bust out more effort to adjust initial pane to suit this little special case.

I will experiment with adjusting the actions with (scrShowAction) and see if that will offer me a single pane solution. The only reason the panes are even there is because I couldn't figure out how to change the actions.

(you know, this is a model I have worked up from my first dockscreen attempt ever- back in April. I still don't know what all can be done with dockscreens!)

[george moromisato]

(you know, this is a model I have worked up from my first dockscreen attempt ever- back in April. I still don't know what all can be done with dockscreens!)

*I* still don't know what all can be done with dockscreens. As I said, you're breaking new ground!

[p.s.: (scrShowAction) is new in 0.99, but I forgot to add it to the list of changes.]

[Periculi]

I thought it must be new, as I searched and searched for anything like that using (help 'scr) in 098d a while back.

Ok, great! I get to put a bunch of the new functions and methods to the test in this mod then.

I can already tell you that I am very pleased with the new topology and system functions you added.