VC++.Net - Editor incorrectly formats CONTROL statements

Issue

This was not a problem under Visual Studio 6. But in VS 2003.Net it persists.

It appears that in some situations the editor incorrectly formats CONTROL statements. This only seems to happen when the control has a Help ID, but it does not always happen even then.

An example:

CONTROL "",IDC_CFG_LISTER_ITEM_COLOUR_FG,"dopus.dropdown.button", 0x5,137,16,30,13,0,0,HIDC_CFG_LISTER_ITEM_COLOUR_FG

In this example, there is one too many parameters. The ",0,0" preceding the HIDC_xxx should only be ",0", eg:

CONTROL "",IDC_CFG_LISTER_ITEM_COLOUR_FG,"dopus.dropdown.button", 0x5,137,16,30,13,0,HIDC_CFG_LISTER_ITEM_COLOUR_FG

When this resource script is complied it produces the following errors:

Compiling resources....\language.rc(290) : error RC2111 : invalid control type.\language.rc(290) : error RC2113 : END expected in dialog.\language.rc(291) : error RC2135 : file not found:.\language.rc(292) : error RC2135 : file not found:.\language.rc(294) : error RC2108 : expected numerical dialog constant

Removing the erroneous ",0" fixes the problem, however the next time any dialog in the resource file is edited, the ",0"s are all put back in.

Workaround

Workaround would be to set the HELP ID property dynamically at runtime.

You can follow the below steps to achieve this:

Let us assume we want to add help id to a TAB control having ID IDC_TAB1.
Open resource.hm file and add the #define as given below to specify value for HELP ID

#define HIDC_TAB1 1000 // some unique value for each control

If resource.hm file does not exist add a new file by name “resource.hm” in the Headers folder of the project. Also add, #include reaource.hm file in dialog editor’s header file.

Go to ::OnInitDialog() function of the Dialog and add the following code.

BOOL CSRTestDlg::OnInitDialog()
{
CDialog::OnInitDialog();

----
----

CWnd* pwnd = this->GetDlgItem(IDC_TAB1);
pwnd->SetWindowContextHelpId(HIDC_TAB1);

return TRUE; // return TRUE unless you set the focus to a control
}

The same is depicted in the figure below:-

However, you would be happy to know, that the issue is fixed in VS2005.Net.
Using VS2003.Net, we created a MFC application (dialog box editor) and added a Tab control on to the editor. Build fails and enumerates the compilation errors as posted by you.

Then the same was emulated using VS2005.Net and the solution build perfectly without any compilation errors. Opening the .rc file complied with VS2005.Net in notepad, you will find that the code generated is what is below:-

CONTROL "",IDC_TAB1,"SysTabControl32",0x0,53,33,50,30,0,HIDC_TAB1

In VS2003.Net, the same procedure resulted in

CONTROL "",IDC_TAB1,"SysTabControl32",0x0,53,33,50,30,0,0,HIDC_TAB1

Part I - Deployment of Office-based Applications(VSTO)

Issue

Create a simple VSTO project, deploy to localhost. If you transfer these files to a computer that has never had Visual Studio 2005 installed, open the workbook, delete Sheet1, then save the workbook under a new name, opening the workbook results in an error that the customization assembly cannot be found.

Resolution

One possible workaround that the you may be able to employ is to rename Sheet1 so that it has a unique name that is not likely to be reproduced and then set the XLSheetVisibility property of this sheet using VBA code so that it is set to xlSheetVeryHidden.By hiding the worksheet in this fashion it would make it more difficult for the client to delete this worksheet from the workbook. The problem as originally understood from the repro steps was that if the user deleted Sheet1 from the Excel workbook that was part of a VSTO solution that once they saved, closed and then reopened the workbook they received the error that the "Customization assembly could not be found or could not be loaded". Based on the description of the problem and as a result of tests if the user was to delete Sheet2 or Sheet3, given the workbook that was provided, then the problem does not occur and the VSTO code successfully loads.So by renaming and hiding Sheet1 from the user it would be less likely that they would delete this sheet and thereby prevent the scenario which results in the error while still allowing the VSTO code to execute. An assumption is made that there is no code contained within the Sheet1 class and/or no .NET controls residing on Sheet1.

It is often recommended that users do not delete sheets from a workbook that is part of a VSTO 2005 solution.

Another way you could do it is to follow the following

There may be another option which would prevent the error from occurring.

If the "Trust access to Visual Basic Project" option is enabled within Microsoft Excel then if the user deletes Sheet1 and there is no code behind or controls on this sheet they should be able to save, close and then reopen the workbook without receiving the error and the VSTO code should still execute.I would also indicate that changing this setting could pose a potential security hazard.By enabling this setting you are allowing macros or automation code to have access to the core Visual Basic objects, methods, and properties which could potentially allow malicious code to be inserted into a workbook and then be executed when the workbook is opened.

For more information please see the url below.http://office.microsoft.com/en-us/assistance/HA011403191033.aspx