SN Bugs: Keep Context Doesn't Work, etc.

Mon Sep 25 08:39:00 GMT 2000

See comments imbedded...

----- Original Message -----
From: "Ian Roxborough" <>
To: <>
Cc: <>
Sent: Sunday, September 24, 2000 23:46
Subject: Re: SN Bugs: Keep Context Doesn't Work, etc.

> Hi Steve, thanks for the concise bug reports.
> Berek wrote:
> > C++ code base. Open new window using F5. Context is checked. New window
> > appears but no context from original window. New window is blank. =
> > Platform is NT 4.0 SP5.
> >
> > Also, single function keys do not work if num lock is on. For example, =
> > when pressing F5 to get new editor window, if num lock is on, nothing =
> > happens. Same thing with F4, etc.
> Anybody got any ideas for a fix or work around?
> (I'm guessing that we need extra bindings to handle
> F5 + numberlock or ??????)

That's all that's necessary. Different key codes for function keys with
numlock and function keys without. Just a couple of additional key code
checks is all that's required.

> > Also, lots of problems going back and forth using "previous page" and =
> > "next page" when more than one view in current window. SN gets confused
> > easily. This last is a real issue for me.
> Yeah, I think the problem is that too many history points get add.
> For example, I double click on a symbol to jump to it's declaration
> in the editor (in the xref tab for example).  SN will add opening
> the file in the editor to the history and then add jumping to the
> correct location in the file to the history.  So if I hit the back
> arrow, instead of going back to the xref, it will jump to the top
> of the file, if I hit the back button again, it should go back to
> the Xref.  Is this the behavior you are seeing?

Not exactly. Can't pinpoint a pattern. Sometimes SN gets completely lost.
Why not just simply have a linked list of views. Each view describes the
frame window and all of the subordinate document windows. Just traverse the
list in two directions. Each element in the list describes what information
to present to the user including document windows, their content, location,
file position, etc.

> I've not really looked at fixing this yet, but it would be really
> nice if this would work without adding the extra points.
> > When using custom editor, SN prepends project directory to file name =
> > passed to editor. For example, SN invokes my editor with =
> >
> > tor.h". "F:\Snav" is the directory where the project db resides. =
> >
> >  is the file id of the file I'm trying to edit.
> I wish Microsoft had based NT on BSD instead of VMS (I'm thinking
> about slashes...).
> Has anybody had similar problems on other platforms?
> Ian.

More information about the Sourcenav mailing list