attachControlToTableCell and a new widget

[Asaf]

This involves both Python and SDK.

What I'm trying to do is to add a button next to some buildings in the city's building list, according to a condition which changes over time.

After a few attempts I did this:
I changed the "BuildingListTable" to have 4 (instead of 3) columns, where I added a new column to the left (previous 0 became 1 etc.). Total width remained the same.

In the loop which goes over the buildings, I checked the condition, and if it was true I used the following (i is the building type):

buttonName = "_NewButton_" + str(i)
screen.setButtonGFC(buttonName, u"", "", 0, 0, 16, 16, WidgetTypes.WIDGET_NEW_WIDGET, i, -1, ButtonStyles.BUTTON_STYLE_CITY_PLUS )
screen.attachControlToTableCell(buttonName, "BuildingListTable", iNumBuildings, 0)

(I used different names, but I spare you these details).

It worked just fine (when I clicked on it it did what I wanted), except for a few problems, some are big, some are much bigger:

1. When entering the city screen, in most cases (but not all), the loading of those specific buildings rows in the table was VERY SLOW.
2. Tool tip didn't show for the button, although it did reach the code in CvDLLWidgetData:: parseHelp for the new widget, and the help string was constructed just fine.
3. Crashes, crashes and more crashes, when entering the city screen. Some gave an error message, such as "Pure virtual function call", and some just threw an exception and died. Tracing their location did me no good since the entire call stack was in the executable.

All these problems happened without clicking this button, so it has nothing to do with what happened after the click.
When I only changed the UI to not have attachControlToTableCell, problems 1 & 3 went away (nothing else changed in the code, including testing for the condition remained).

However, when instead of adding a column with a button I just changed the color of the text of the building name and changed its widget type, I couldn't even get the click to work, and the tool tip didn't work either.

I'd appreciate any help I can get on this.

 

[Asaf]

So I understand 'attachControlToTableCell' is a tough cookie...
I've given it up. I now use textual cells with a new widget to modify its behavior.

I'll expand my 2nd question with what I've learned so far, maybe it'll give an idea to someone:

It appears that when giving a new widget to a text cell in the buildings table, whether or not this widget works (tooltip + click) depends on the position of this widget in the widgets Enum!

I tried a few places, but placing it before WIDGET_PYTHON or at the end of the list (before NUM_WIDGET_TYPES) will cause it not to work.

My current position (right after WIDGET_HELP_PROMOTION) works just fine.

I'm afraid that there's a problem I'm not aware of (another place which holds this list?), which might cause other widgets to stop working because of the one that I added.

And just in case you were wondering, I added it to the python widget types enum in CyEnumsPythonInterface().

Any ideas?

 

[The_J]

Some background of your idea might help. What exactly do you want to achieve?

 

[Sephi]

So I understand 'attachControlToTableCell' is a tough cookie...
I've given it up. I now use textual cells with a new widget to modify its behavior.

I'll expand my 2nd question with what I've learned so far, maybe it'll give an idea to someone:

It appears that when giving a new widget to a text cell in the buildings table, whether or not this widget works (tooltip + click) depends on the position of this widget in the widgets Enum!

I tried a few places, but placing it before WIDGET_PYTHON or at the end of the list (before NUM_WIDGET_TYPES) will cause it not to work.

My current position (right after WIDGET_HELP_PROMOTION) works just fine.

I'm afraid that there's a problem I'm not aware of (another place which holds this list?), which might cause other widgets to stop working because of the one that I added.

And just in case you were wondering, I added it to the python widget types enum in CyEnumsPythonInterface().

Any ideas?

I had a similar problem which I could fix by disabling Popups for the current active screen.

 

[Asaf]

Thank you for your help

Some background of your idea might help. What exactly do you want to achieve?

I wanted to keep it as a surprise
Oh well:
I work on BTS 3.19 (no BUG or anything). My mod lets some buildings accumulate experience when they build units of specific categories, and then gain specific promotions in these buildings for units of these categories which are built in this city (a complicated sentence ).

To do that I need to be able to change the display of buildings which have an available promotion in the buildings table in the city screen, and I need to be able to click on them to open the relevant popups.

The basic functionality works, including the UI (I created a new widget in the SDK and new popups, also in the SDK), but with the problem I mentioned (whether it works or not depends on its position in the enum).

I had a similar problem which I could fix by disabling Popups for the current active screen.

I'm not sure how to do that, and if I understand it correctly then I don't want to do that since I want to open popups as a result of clicking this widget.

Why would that make a difference? Is there another way to fix/bypass this?

I've come across a few other problems which might be related:
- In the civilopedia, the Exit button does not work.
- In the civics screen, the Revolution button does not work. It just closes the screen, but does not revolt.

I think that I somehow caused these widgets to stop functioning, the same way I prevent my widget from functioning when I place it in the wrong place in the enum. I'll debug it soon (hadn't had a chance yet) to see if I actually get to the relevant functions in the SDK.

It looks like the list of widgets is duplicated somewhere else (in the exe itself?) and changing it in the SDK (and in its exports to python) is sometimes just not enough...

 

[Sephi]

Why would that make a difference? Is there another way to fix/bypass this?

there is a way to bypass this but you need to test first if this is the problem. Just to prevent any misunderstandings, the python function I am talking about is

		screen.showScreen(PopupStates.POPUPSTATE_IMMEDIATE, False)

 

[Asaf]

I actually use the popups in the SDK, so I use

gDLL->getInterfaceIFace()->addPopup()

and

gDLL->getInterfaceIFace()->popupLaunch()

 

[Asaf]

Moving the widget to the end of the enum (before NUM_WIDGET_TYPES) now works (must have done something wrong earlier), and it solves the civics 'revolution' button and the pedia exit button.

Interesting point: If I place my widget in the enum between these two (WIDGET_REVOLUTION and WIDGET_CLOSE_SCREEN), then only the earlier one (revolution) works.

I guess there is another copy of the enums compiled into the exe. Another hint for this is the fact that there's the _USRDLL definition, implying that this file might also compile when this is not defined...

Oh well. I hope there are no other hidden problems. Thank you for your time.

 

[EmperorFool]

Likely you needed to fully recompile as some .cpp files were not seeing the changed enum values. Whenever you modify a header (.h) file, do a clean and build.

 

[Asaf]

Likely you needed to fully recompile as some .cpp files were not seeing the changed enum values. Whenever you modify a header (.h) file, do a clean and build.

Thanks, but that is definitely not the problem.

 

[EmperorFool]

As long as you don't change the values of any existing enums you should be okay. The EXE is compiled against CvEnum.h as well, and it isn't recompiled when you change it obviously.

 

[Asaf]

As long as you don't change the values of any existing enums you should be okay. The EXE is compiled against CvEnum.h as well, and it isn't recompiled when you change it obviously.

That's what I figured, so I moved all my new Enum values to the end of each enum.
I wish Firaxis would add a comment about it in the code.
Actually I wish Firaxis would comment their code in general

Thanks.