Statements skipped & breakpoints lost in code block (C++ .NET)

I'm not too sure this is in the right place as it might be something up with
my managed C++. Any which way someone might be able to help...

The following function is a member of a derived form class, which is called
to refresh the contents of a number of treeviews:
[code]
Void RefreshViews(){
adminTree->Nodes->Clear();
clericalTree->Nodes->Clear();

for(int i = 0; i < m_plugins->Count; i++){
PlugIn* pi = dynamic_cast<PlugIn*>(m_plugins->get_Item(i));
if(m_roles & pi->get_Role()){ // Filter plugins by user group membership

// Return view associated with role (adminTree or clericalTree)
TreeView* view = GetRoleView(pi->get_Role());

// Add plugin entries to selected treeview
ArrayList* entryList = pi->get_TreeItems();
for(int i2 = 0; i2 < entryList->Count; i2++){
TreeEntry* te = dynamic_cast<TreeEntry*>(entryList->get_Item(i2));
TreeNode* node = new TreeNode();
node->set_Text(te->get_Text());
view->Nodes->Add(node);
}
}
}

TreeView* GetRoleView(Int32 role){
/* Return the treeview associated with specified role */
if(role & IFDB_ADMIN)
return adminTree;
else if(role & IFDB_CLERIC)
return clericalTree;
return NULL;
}
[/CODE]

The code following the call to GetRoleView is not being executed; Even
though it is in the same code block and it is not a control statement, the
debugger just jumps to the end of the first loop.
When I tried replacing the call to GetRoleView with the code copied from the
function the view variable was assigned correctly and execution proceeded, as
expected, to the point where a new TreeNode object is allocated in the second
loop.
Then the same thing happened there! The statements following the "TreeNode*
node = new TreeNode();" line are not executed and control returns to the end
of the loop again!

I thought maybe it was an out of date object file but tried a clean build
and the problem persisted.

Any ideas what is causing this problem? I cant see anything wrong with
either of the statements.

regards
.

Relevant Pages

  • Re: I want to learn forth but...
    ... on each pass of the loop. ... deeper in the execution stack. ... faster than even a register bank of any real size. ...
    (comp.lang.forth)
  • Re: Reducing build-times for large projects.
    ... If the line before it executed, then the very next inline code has ... if your architecture does speculative execution and fetch. ... > THE FUNCTION THAT IS ALREADY IN CACHE! ... Loop unrolling "works" because you get to do N iterations worth of the ...
    (comp.lang.cpp)
  • Re: Running a background task
    ... background task that runs more or less forever, while normal execution ... entry On_String (String: in SideAB) ... It's generally not a good idea to reuse the identifier "String", since it hides the predefined type String, which will cause confusing error msgs if you ever try to use that type. ... end loop; ...
    (comp.lang.ada)
  • Re: Python indentation
    ... >>indentation aimlessly wandering out, then in, then out again, then in at ... > It is as much a single flow of execution as an if elif else. ... >>assembly languages have a loop structure quite so ugly as that. ... it's confusing and misleading too. ...
    (comp.lang.python)
  • Re: I want to learn forth but...
    ... on each pass of the loop. ... deeper in the execution stack. ... memory, and the part I quoted gave another loop approach (cyclic ...
    (comp.lang.forth)
Loading