|Anonymous | Login | Signup for a new account||2013-05-20 01:38 CEST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000963||VCMI||GUI - Hero screen / Exchange window||public||2012-05-19 21:19||2012-05-20 01:16|
|Platform||PC||OS||Windows 7||OS Version||SP1|
|Target Version||0.89||Fixed in Version|
|Summary||0000963: Clicking artifacts in hero window causes crash|
|Description||At least two artifatcs need to be present.|
Tested in r2695 (before my latest commit related to commander artifacts)
|Steps To Reproduce||Use attached map. Click Equestrian gloves on hero screen - assertion fail related to GUI destructors.|
|Additional Information||I'm pretty sure in the morning it worked ok.|
|Tags||No tags attached.|
|Attached Files||Testy7 Arts2.h3m [^] (3,133 bytes) 2012-05-19 21:19|
Will fix later today.
Now I'm completely convinced that our GUI system needs some fixing. At least to automate deletion\activation\deactivation of objects.
|Resolve in rev 2697|
The delChildNUll method has a second argument that allows automatic deactivation before deleting. It may be worth to switch it default value, current behaviour is indeed overly strict (aking it easy to shoot yourself in the foot.
However I believe listSelection picture should be created in constructor — it is not changed upon update anyway. Switching heroes just creates new hero window, update() is called after construction and upon artifacts movement.
1) There is no way to pass "activate if needed" during construction so you won't solve this issue completely
2) listSelection may not be present (or at least inactive) - if selected hero is in garrison or tavern. But making it inactive will need even more management!
In some cases activate/deactivate code takes too much place despite that in (almost) all cases it can be moved to constructor or method like addChild.
One more problem is moveChild\addChild - even if you don't care about current parent you still need to write code like this:
if (parent) move() else add()
I think that in tabs\lists half of code was such children management.
And one more problem that started to appear recently - positioning. It's quite difficult to track who and when moved this object incorrectly. Probably CIntObject::pos should be protected somehow.
|2012-05-19 21:19||Warmonger||New Issue|
|2012-05-19 21:19||Warmonger||File Added: Testy7 Arts2.h3m|
|2012-05-19 21:24||Warmonger||Steps to Reproduce Updated||View Revisions|
|2012-05-19 21:42||Ivan||Assigned To||=> Ivan|
|2012-05-19 21:42||Ivan||Status||new => assigned|
|2012-05-19 21:43||Ivan||Note Added: 0002505|
|2012-05-19 23:39||Ivan||Note Added: 0002506|
|2012-05-19 23:39||Ivan||Status||assigned => resolved|
|2012-05-19 23:39||Ivan||Fixed in Version||=> 0.89|
|2012-05-19 23:39||Ivan||Resolution||open => fixed|
|2012-05-20 00:38||Tow||Note Added: 0002507|
|2012-05-20 00:51||Tow||Fixed in Version||0.89 =>|
|2012-05-20 01:16||Ivan||Note Added: 0002510|
|Copyright © 2000 - 2012 MantisBT Group|