Author Topic: preventing search in selection and opening new untitled text file in slickedit  (Read 10651 times)

davecazz

  • Community Member
  • Posts: 17
  • Hero Points: 1
Hi, I have a couple more questions.

I like having persistent blocks available to me as I work. however, it looks like search will always look in the active selection if one exists rather than continuing to look in the rest of the file... is there anyway to override this so it always ignores the selection.... I was thinking of just looking in the macro files for a way to disable this functionality but I figured I could ask first rather than changing the code.

Also, I noticed that if I create a new untitled text file in eclipse, it doesnt choose slickedit as the editor, I think I have all my extensions set to use slickedit but unfortunately, a new text file odesnt have an extension until it has been saved. I usually use unsaved files as scratch pads so it would be helpful to use slickedit to view/edit these.

Lee

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1299
  • Hero Points: 130
If you have an active LINE selection or a CHAR selection greater than 1 line then the Find and Replace tool window will automatically default the Look in: range to <Current Selection>.  Is this what you are referring to?  There is no option or def-var to disable this behavior, but I can add that as a Feature Request.  If your up for changing it in the macro source then have a look in macros\tbfind.e in _init_findstring, there is a section in there which restricts the range to the current selection (line 830-ish, depending on your version).

I'm hoping Ryan can jump in on the second question.

davecazz

  • Community Member
  • Posts: 17
  • Hero Points: 1
Awesome, thanks.

I feel a little guilty about asking about so many customizations (although I probably have a lot more) but I really appreciate you pointing me in a direction where I can make these changes locally.

Once things settle down, I will add a thread with all my source edits in case anyone else is interested or you want to add them to your next update, I made some customizations that include not unselecting the current selection when you first click into the editor, and only doing the mouse select once you start dragging. and I added some new panning support that goes a little beyond the panning discussion on the board, and made it so moving left on the first column wraps to the previous line but moving right at the end of the line moves into virtual space.

Ryan

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 986
  • Hero Points: 77
Quote
Also, I noticed that if I create a new untitled text file in eclipse, it doesnt choose slickedit as the editor, I think I have all my extensions set to use slickedit but unfortunately, a new text file odesnt have an extension until it has been saved.

Unfortunately the File Association manager only lets you associate extensions with editors.  It won't let you just specify "*", or " ", or anything like that.  It could be that this is something I don't know how to do, but I don't think it's possible.

- Ryan

davecazz

  • Community Member
  • Posts: 17
  • Hero Points: 1
Thanks, I will look around on the eclipse boards and post a solution if I find one.

davecazz

  • Community Member
  • Posts: 17
  • Hero Points: 1
so, I think that I have some insight into these issues.

The first one has to do with flex. flex allows us to have a linked folder outside of the main workspace folder. if I open one of these files that is outside of the workspace folder (but in the workspace), bookmarks dont work. 

If I do the same with a file that is in the actual workspace folder, it works fine. also, I noticed that the typical eclipse project doesnt allow files that are outside of the workspace folder to be included in the workspace without copying them over.

So, it looks like this is an eclipse deal, or somehow if I open a file from slickedit or the file system, somehow, I have to reroute it through the flex view or do something similar to what the flex view is doing.


the other issue is with associating an untitled text file with slickedit. For this, it looks like the only way to do this, is to rewrite their UntitledTextFileWizard and force it to open slickedit instead of choosing the default editor (which always comes up as the default eclipse editor because of a missing file extention). it looks like there is a line of code there that allows me to do it. instead of rewriting their wizard, I guess it's possible to add a custom "scratchpad" file wizard these changes.


Both of these issues are kind of low priority for me, getting the debugger running is my number one issue right now. As it is, I am starting to rely on traces instead of stepping through code. Have you tested support for the flex debugger with slickedit? is this something that should work? if it's not, then I might need to find a way to set the default editor to the flex editor when going into debug mode, reopening all files in that editor. and doing the reverse when exiting debug mode.



Ryan

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 986
  • Hero Points: 77
Quote
So, it looks like this is an eclipse deal, or somehow if I open a file from slickedit or the file system, somehow, I have to reroute it through the flex view or do something similar to what the flex view is doing.

If you are ever wondering if it's a bug in Eclipse or a bug with SlickEdit Core for Eclipse, you can always try out the operation in the normal Eclipse environment.  For example, with this one...open one of these files from a linked folder in a normal Eclipse editor.  Can you set a bookmark by right-clicking in the margin?  If not...it's a limitation in Eclipse.

Quote
the other issue is with associating an untitled text file with slickedit. For this, it looks like the only way to do this, is to rewrite their UntitledTextFileWizard and force it to open slickedit instead of choosing the default editor (which always comes up as the default eclipse editor because of a missing file extention). it looks like there is a line of code there that allows me to do it.

I'll file a feature request for this for our next release...seems like this is something we could code up, and I think it's how most people using our plug-in would like extensionless files to be handled.  Might have to make it an option, but, whatever.

Thanks for the feedback.

- Ryan