Recent changes to patches

#9 Windows: fix handle leak

Benoit Blancard — Sat, 22 Oct 2022 05:53:59 -0000

status: open --> closed
assigned_to: Benoit Blancard

#9 Windows: fix handle leak

Benoit Blancard — Sat, 22 Oct 2022 05:53:23 -0000

Hi Carlo,
Thanks for your patch! I have uplaoad it in thrunk

Windows: fix handle leak

Carlo Bramini — Wed, 21 Sep 2022 12:24:09 -0000

Attached patch fixes an handle leak for the Windows ports.

Windows: fix handle leak

Carlo Bramini — Wed, 21 Sep 2022 12:24:09 -0000

Ticket 9 has been modified: Windows: fix handle leak
Edited By: Benoit Blancard (benblan)
Status updated: 'open' => 'closed'
Owner updated: None => 'benblan'

#7 Add minimap implementation

Bohdan Stelmakh — Sat, 02 Mar 2013 15:09:01 -0000

status: open --> closed
milestone: --> FeatureAdded

#8 Fixes for crashes in research menu and more

Bohdan Stelmakh — Sat, 02 Mar 2013 15:06:00 -0000

status: open --> closed

#8 Fixes for crashes in research menu and more

Roland Haeder — Thu, 17 Jan 2013 05:32:23 -0000

How about isDead() and isAlive()? Encapsulation is never a bad idea and always recommended to "hide" complex functionality behind a simple method/function call.

As for the asserts, they don't hurt anywhere. If a variable is NULL which is not wanted at that points where I inserted them, you should abort your program and investigate that situation. The purpose of these threee asserts is to aid debugging of unexpected situations (as the logic of this program is complex something might go wrong). If you do not know what asserts are for, don't blame me for inserting them. I had that situation that these checked variables were NULL, so I added an assert on that condition (I have improved it with next upload), started my debugger and got that assert so I could back-trace it to were it was caused.

As for the assert in setHealth() in some situations you set a negative health (-1 e.g. in vehiclemanager.cpp) but then setHealth() checks if n < 0 and if so, sets it to zero. This means, you "fix" <0 vales to 0 which I concluded, that you want at lowest value 0 being set. The assert makes sure that you don't set any values below zero while you program and test your code.

As for disableFundBox(), it is almost the same as for isDead/Alive() methods, as they encapsulate code/functionality behind a simple method call. Here, disableFundBox() - as the name suggests - disables the whole fund box (+/- controls and value output).

First, it sets incrFundId_ and decrFundId_ to not being visible (means, not click-able). Then it sets the value which is fundCurrLblId_ responsible for, to empty, then makes it invisble. This may look like redundant but it is just a cleaner programming way. The last step is to empty the "research title" referenced by searchTitleLblId_, as you don't need it.

In ResearchMenu::ResearchMenuhandleLeave() I have added two lines to set two class "attributes" (or fields, or however you call them) to NULL is this leaves a much cleaner state behind. It is like leaving your house but left all lights and TV turned on.

In Research::init() your code caused a warning which I have now fixed. This requires Research::researchCnt being initially set to zero, not one.

The methods isMaxFunding() and isMinFunding() are again for better encapsulation.

In ped.h I added an enum called "objBaseSpeed" which hold all "actor's" base speeds in one place to make easy balancing possible (as I mentioned in my previous comment).

In ResearchManager::complete() I use a local variable "researchValid" which is being set to "true" if a research has really been completed. And if it is so, the fireGameEvent() method is being called. Without this, I had crash on debriefing screen when a research completed while I was in-game (on the map, not in menu).

#8 Fixes for crashes in research menu and more

Bohdan Stelmakh — Thu, 10 Jan 2013 10:23:11 -0000

As for the rest, I will not accept your patch. You do not present me information requried to reproduce errors to understand purpose of those asserts, you insist on adding disableFundBox which I don't like at all.

#8 Fixes for crashes in research menu and more

Bohdan Stelmakh — Thu, 10 Jan 2013 09:34:47 -0000

Indeed I have forgotten to add 2 files, also I have added properties to files you mentioned.

#8 Fixes for crashes in research menu and more

Roland Haeder — Thu, 10 Jan 2013 01:20:33 -0000

src/menus/squadselection.cpp has Windows line breaks (\n\r()), but all other files have Unix (\n). You should set "svn:eol-style" property to native. Then everyone can commit with his/her line-breaking characters and nothing got changed entirely.

!/bin/sh

find -type f -name ".cpp" -exec svn propset svn:eol-style "native" {} \;
find -type f -name ".h" -exec svn propset svn:eol-style "native" {} \;

This script might help. :) To the asserts I have added, I had crashes there (mostly SIGABORT and segfault). So I added some asserts to help debugging it. It is in my oppinion advisable to check for important parameters that they are set as expected and not just let them go. Anyway, if asserts and method calls hurts performance on your system, sorry to ask, do you run it on a C16? ;-)