MantisBT

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000963VCMIGUI - Hero screen / Exchange windowpublic2012-05-19 19:192014-05-30 17:41
ReporterWarmonger 
Assigned ToIvan 
PrioritynormalSeverityblockReproducibilityalways
StatusclosedResolutionfixed 
PlatformPCOSWindows 7OS VersionSP1
Product Version 
Target Version0.89Fixed in Version 
Summary0000963: Clicking artifacts in hero window causes crash
DescriptionAt least two artifatcs need to be present.

Tested in r2695 (before my latest commit related to commander artifacts)
Steps To ReproduceUse attached map. Click Equestrian gloves on hero screen - assertion fail related to GUI destructors.
Additional InformationI'm pretty sure in the morning it worked ok.
TagsNo tags attached.
Attached Files? file icon Testy7 Arts2.h3m [^] (3,133 bytes) 2012-05-19 19:19

- Relationships

-  Notes
(0002505)
Ivan (developer)
2012-05-19 19:43

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.
(0002506)
Ivan (developer)
2012-05-19 21:39

Resolve in rev 2697
(0002507)
Tow (developer)
2012-05-19 22:38

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.
(0002510)
Ivan (developer)
2012-05-19 23:16

Yes but:
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.

- Issue History
Date Modified Username Field Change
2012-05-19 19:19 Warmonger New Issue
2012-05-19 19:19 Warmonger File Added: Testy7 Arts2.h3m
2012-05-19 19:24 Warmonger Steps to Reproduce Updated View Revisions
2012-05-19 19:42 Ivan Assigned To => Ivan
2012-05-19 19:42 Ivan Status new => assigned
2012-05-19 19:43 Ivan Note Added: 0002505
2012-05-19 21:39 Ivan Note Added: 0002506
2012-05-19 21:39 Ivan Status assigned => resolved
2012-05-19 21:39 Ivan Fixed in Version => 0.89
2012-05-19 21:39 Ivan Resolution open => fixed
2012-05-19 22:38 Tow Note Added: 0002507
2012-05-19 22:51 Tow Fixed in Version 0.89 =>
2012-05-19 23:16 Ivan Note Added: 0002510
2014-05-30 17:41 beegee Status resolved => closed

Site | Forums | Wiki | Slack | GitHub


Copyright © 2000 - 2024 MantisBT Team
Hosting provided by DigitalOcean