bugfix(worldbuilder): Fix script condition selection when editing newly created condition

[ViTeXFTW]

• Fixes World Builder: Editing a newly created map script condition changes another condition #2066

Update
The only issue was the m_index not being updated in the setSel() function - the reason for the confusion was improper build directory after the first fix was added. Resolved with deleted build dir and recompilation.

Description
This PR fixes an issue in WorldBuilder where the addition of a new condition in the script modal didn't update the m_index and left it stale. Which resulted in incorrect update of condition after editing the condition again immidiatly.

Root Cause

1. Missing index update in setSel(). When it was called to select a newly created condition, it updated the visual selection and pointer members (m_orCondition, m_condition) but failed to update m_index. This left m_index stale.

2. Incorrect OrCondition saved in OnNew(). When adding a condition with no selection, OnNew() saved m_orCondition (which was nullptr) instead of the first OrCondition from the script. After loadList() triggered OnSelchangeConditionList(), setSel(nullptr, pCond) failed to find a match and exited without updating any state.

Fix in ScriptConditions.cpp

1. setSel(): added m_index = count; in

   GeneralsGameCode/GeneralsMD/Code/Tools/WorldBuilder/src/ScriptConditions.cpp

   Lines 167 to 172 in a4f89bc

   	if (m_orCondition==pOr && pCond==nullptr) {
   	pList->SetCurSel(count);
   	m_index = count;
   	enableUI();
   	return;
   	}

   
   

   GeneralsGameCode/GeneralsMD/Code/Tools/WorldBuilder/src/ScriptConditions.cpp

   Lines 176 to 181 in a4f89bc

   	if (m_condition == pCond) {
   	pList->SetCurSel(count);
   	m_index = count;
   	enableUI();
   	return;
   	}

2. OnNew(): added *pSavOr = m_orCondition ? m_orCondition : m_script->getOrCondition();

[greptile-apps]

Greptile Overview

Greptile Summary

This PR fixes a state synchronization bug in the WorldBuilder's script condition editor. When setSel() was called to select a newly created condition (e.g., after OnNew()), it correctly updated the visual selection (pList->SetCurSel(count)) and pointer members (m_orCondition, m_condition), but failed to update m_index. This left m_index pointing to the previously selected item's index.

The bug manifested when editing a newly created condition immediately after creation - the editor would update the wrong list entry because it used the stale m_index value in operations like DeleteString(m_index) and InsertString(m_index, ...).

Fix: Added m_index = count; at both return points in setSel() where a match is found (lines 169 and 178), ensuring the index stays synchronized with the visual selection and pointer state.

Files Changed:

• Applied identical fixes to both Generals/ (vanilla) and GeneralsMD/ (Zero Hour) versions
• Changes are minimal, targeted, and solve the root cause described in issue World Builder: Editing a newly created map script condition changes another condition #2066

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The fix is a straightforward state synchronization correction that adds two missing index assignments. The changes are minimal (2 lines per file), logically sound, and directly address the root cause. The fix matches the existing pattern used in OnSelchangeConditionList() which already sets m_index = count; when updating selection. Both vanilla and Zero Hour versions receive identical fixes, maintaining code parity.
• No files require special attention

Important Files Changed

Filename	Overview
Generals/Code/Tools/WorldBuilder/src/ScriptConditions.cpp	Fixed missing m_index updates in setSel() to keep index state consistent with visual selection
GeneralsMD/Code/Tools/WorldBuilder/src/ScriptConditions.cpp	Fixed missing m_index updates in setSel() to keep index state consistent with visual selection

_{Last reviewed commit: 7023b4b}

[xezon]

It's difficult to understand if this is connect. Can someone else review this?

[Caball009]

It's difficult to understand if this is connect. Can someone else review this?

I can take a look at it later.

[Caball009]

First change looks right and directly related to the issue. Not so sure about the second change. Is there a visual cue that there's an issue if the second change isn't implemented?

[ViTeXFTW]

Not so sure about the second change. Is there a visual cue that there's an issue if the second change isn't implemented?

I will do some more testing and provide an update.

I also initially thought that the first change would fix the behavior however when I recompiled, I still observed the same behavior - however I didn't do a clean rebuild of the codebase at each of the change points, but that shouldn't have an impact right?

[ViTeXFTW]

@Caball009 I've updated the PR to only contain the first fix - the issue was with the recompilation as per the updated PR text.

[Caball009]

Looks correct.

Needs to be replicated in Generals.