There is no Command window. about knightonline HOT 15 CLOSED

I don't believe that the command window is being loaded into the client at all. Looks like we should make a new UI class for curtail (cmd window). I can start laying out the class and the H hotkey to open/close the window. Unless I haven't found it which I'd like confirmation that I'm not missing something.

from knightonline.

It isn't implemented, no.

from knightonline.

Started working on this. Something goofy is happening when opening/closing dialog. Will have to add strings for commands.

• Fix opening and closing of UI w/ 'H' key.
• Add commands to UI window
• Process commands
• Access the command list through the lower command window

CUICmdList Commit 1
CUICmdList Commit 2

from knightonline.

I figured out what was going on with opening/closing of dialog. The closing and opening of dialog with 'H' key is working now, as well as, using the x close on the window.

from knightonline.

I know it's minor, but the name of that class is confusing. It's not the first thing I'd think of when trying to find that UI; perhaps it should be renamed such that it's at least similarly named to its name in UIs_us.tbl, e.g. CUICmdList?

Also there's an existing implementation for commands it can interface with; chat already handles commands (I don't remember what state it is in this repo, may need slight reverting, but it exists).

from knightonline.

I agree. I'll be changing the name. The reason I started with curtail is that's what it is called in the .dxt file and that's how I originally tracked it down. Lol idk what curtail even means feels like that got lost in translation.

from knightonline.

Is there an example where strings are loaded into some portion of the UI that can be selected? I'm having trouble deciding how this should work and haven't found a good example yet. I'm assuming I'll place the commands on icons or something of the sort. Then when an icon (whatever) is selected load a subset of commands. Then upon an icon subset selection, the command gets handled.

from knightonline.

Huh? I don't follow.

There's 2 listboxes; one for the command groups and the other for the selected commands.
You populate the first with the command groups from the resources, and then upon selection repopulate the command list itself with the selected commands.

All of the strings are loaded via _LoadStringFromResource().

When the commands are triggered, you trigger its respective command via handler in CGameProcMain. Likewise when it should prompt for string input (e.g. for names), upon submission of that one's input UI, it should trigger the respective command there with the provided input as an argument.

If command handling via chat is in a good place (it may need to be reverted and the command order updated if not, because a lot of stuff related to resources was tampered with early on in this repo), this should be fine. If not, that also needs to be addressed independently of this UI.

from knightonline.

Made some progress.. it might be cleaner to create a list object for each category. Then I can load the strings in once on initialization and after that display the correct list based on what category a user selects.

CUICmdList Commit 3

from knightonline.

@twostars I've implemented a map instead that I iterate over to pull in the text resources. Hopefully, this is a little cleaner than manually loading in each resource.

• Add tool tips to commands

still need to figure out how to do this properly

CUICmdList Commit 4

from knightonline.

Regarding the extra commands being loaded, I wouldn't worry about them. In my implementation I just left them.

Can always just remove them from the TBL itself if they bother you, but they don't harm anything.

from knightonline.

I appreciate all the suggestions you made on the last commit.

CUICmdList Commit 5

from knightonline.

bool CUICmdList::ReceiveMessage(CN3UIBase* pSender, uint32_t dwMsg)
{
	if (NULL == pSender) return false;

	if (dwMsg == UIMSG_BUTTON_CLICK)
	{
		if (pSender->m_szID == "btn_cancel")
			SetVisible(false);
	}
	else if (pSender == m_pList_CmdCat) {
		uint8_t iSel = m_pList_CmdCat->GetCurSel();
		UpdateCommandList(iSel);
	}
	else if (pSender == m_pList_Cmds) {
		uint8_t iSel = m_pList_Cmds->GetCurSel();
		ExecuteCommand(iSel);
	}
	
	return false;
}

Each individual case here that handles the event should be returning true. This is meant to stop feeding it back up the chain once we've handled it (note that mgame often doesn't do this, but they should be -- they tend to just consider the UI handled it even when it doesn't).
Additionally, it should default back to passing it to CN3UIBase::ReceiveMessage() so it can actually do so (i.e. feed it back up the chain).

		if (pSender->m_szID == "btn_cancel")

This should be checking m_pBtn_cancel(sp), since you store it, rather than the ID.

Finally, these cases:

	else if (pSender == m_pList_CmdCat) {
		uint8_t iSel = m_pList_CmdCat->GetCurSel();
		UpdateCommandList(iSel);
	}
	else if (pSender == m_pList_Cmds) {
		uint8_t iSel = m_pList_Cmds->GetCurSel();
		ExecuteCommand(iSel);
	}

These need to be more specific about the event we're actually handling here, e.g.:

	else if (dwMsg == UIMSG_LIST_SELCHANGE)
	{
		// Changed the selected group
		if (pSender == m_pGroupList)
		{
			UpdateList(GetSelectedGroup());
			return true;
		}
	}
	else if (dwMsg == UIMSG_LIST_DBLCLK) // this is probably better off as a single-click, checking if we're already selected and acting accordingly
	{
		// Double-clicked a command
		if (pSender == m_pCommandList)
		{
			SelectCommand(GetSelectedCommand());
			return true;
		}
	}

(I was lazy and just copied it straight from mine, so don't mind that :P)

from knightonline.

Added in a new class and made some slight changes to CUICmdList. Starting to get things functioning together. Commands are being sent down to the chat command handler. Seems to work at least the commands that are being handled.

Commit 6

from knightonline.

We can close this one.

from knightonline.