1 Reply by timaki

  • timaki
  • Member
  • Offline
  • Registered: 2006-10-18
  • Posts: 9

Re: But in "." command

OOPS: That should be "Bug in '.' command", not "But...." Sorry about that.

There is an intermitent problem with the "." (repeat) command in ViEmu/VS. I am converting a large Visual Basic project from Oracle the SQL Server, and I have to update many of the embedded SQL statements. One such SQL feature that must be converted is to rename the NVL() function to ISNULL(). It's an easy change, and one that is perfect for the "." command. When my cursor is at the start of NVL(), I just type:

cwISNULL<ESC>

(Of course, "<ESC>" means the escape key.) Then I move to the next NVL() in the code and press ".", and it converts to ISNULL() expected. Great.

However, there are times when I convert the first NVL() and then use the "." on the next one, and nothing changes. The only thing that happens is that the cursor moves to the left one position. At those times I have to issue the "cw" command for every change I want to make. I also noticed that other repetitive changes that I had used "." for in the past no longer work.

At some later time, everything will start working again. I have not determined a cause. I have no special add-ins in Visual Studio. I am using VS2005 on Windows XP Pro with all applied updates. I am working within a standard VB code window. I can't think of anything I am doing that is non-standard, as I am spending my entire day just modifying existing code. I'm not even building or running the code at this point.

There must be some flag within ViEmu that is causing "." to interpret things differently, or that is causing your special buffer-analysis code to read the changes differently. Thanks for checking this.

Last edited by timaki (2006-10-18 15:31:34)

2 Reply by Jon_Symnum

  • Jon_Symnum
  • Administrator
  • Offline
  • Registered: 2006-01-20
  • Posts: 1,658

Re: But in "." command

Sure, this is due to the buffer-sensing tech not working correctly. I will look into it in detail next week, I apologize for not being able to investigate it before.

Best regards,

  Jon

3 Reply by timaki

  • timaki
  • Member
  • Offline
  • Registered: 2006-10-18
  • Posts: 9

Re: But in "." command

Additional information that may help.

The problem seems to be on a per-source-file basis. If I have multiple source files open at once, the "." problem can appear in one file, but have no problem in another file.

If I close a file (both source and designer) in Visual Studio, and then reopen that source file, the problem goes away for that file. That's my workaround.

If I keep a source file open that was having the problem and then close Visual Studio completely, the next time I open that project in Visual Studio, naturally the source file will still be open. In this case, the problem does not go away.

4 Reply by Jon_Symnum

  • Jon_Symnum
  • Administrator
  • Offline
  • Registered: 2006-01-20
  • Posts: 1,658

Re: But in "." command

Hmmm... the persistence is weird. I'll send you an instrumented build in a few days to generate logs that may help in pinpointing the problem.

Thanks,

  Jon

5 Reply by timaki

  • timaki
  • Member
  • Offline
  • Registered: 2006-10-18
  • Posts: 9

Re: But in "." command

I discovered the problem, or at least what triggers the problem. If you open a new code window, the "." command works just fine. However, if you split the code window (i.e., using the Window --> Split Visual Studio menu command), the "." feature stops working until you close the window and reopen it.

6 Reply by Jon_Symnum

  • Jon_Symnum
  • Administrator
  • Offline
  • Registered: 2006-01-20
  • Posts: 1,658

Re: But in "." command

Cool, thanks a lot for the detailed steps to repro it. I will have a look at it next week and get back to you, hopefully it will be an easy fix.

Thanks and best regards,

  Jon

7 Reply by Jon_Symnum

  • Jon_Symnum
  • Administrator
  • Offline
  • Registered: 2006-01-20
  • Posts: 1,658

Re: But in "." command

I've fixed this in 2.0.39:

  http://forums.ngedit.com/viewtopic.php?id=110

Regards,

  Jon