Recent Posts

Pages: [1] 2 3 ... 10
1
SlickEdit 2017 v22 Beta Discussion / Re: File -> New request
« Last post by jporkkahtc on August 21, 2017, 07:35:19 pm »
That would work ... you can always type ".\filename"

Does completion get turned off again if I deleted the leading ".\" ?
2
Fixed for beta 3.  Looking back, I think we've had to address this problem before, but the fixes never ended up working in all cases, because I missed the root cause.  The short version is the logic was good, but the data about where cursors/hotspots were was not so good.  Your example made that obvious, since there are no hotspots or cursors in a position to make us retain the space.

Thanks again for the report.
3
Ubuntu 16.04.2
It is really inconvenient to have to manually resize the window every time for 3 way merge and DIFFzilla instead of just hitting maximize. This doesn't look to be changing for SE 2017... Any comments from the SE team, I'm pretty sure these are available in Windows version.
They seem to be there on Ubuntu 16.04 as well.  On the left side, there's a round button with an X, and another with a square. The square is maximize.  Do you not see this?  It's possible it's a window manager thing, but I'm using the default one.

Also, I've been consistently seeing that if I open a 3-way merge or diff and have changes but try to just x out of the program the "Do you wish to save changes ..." dialog is not in focus and hidden behind the merge/diff tool. I have to click away and back to get it in focus.

I can't reproduce this one either.  In fact, I can't make it drop behind.

What window manager are you using?
4
Reproduced.  I think I know what this is.  We sometimes preserve spaces that otherwise wouldn't be allowed if a cursor is adjacent to the space.  That's desirable for some situations, like an alias expansion like this: "if (%\c) %\c".  But it doesn't make sense for your example, since we already know the brace is going to be on the next line.

Thanks for the report, I can probably get this in for beta 3.
5
SlickEdit® / Re: Need help with tag symbols?
« Last post by Dennis on August 21, 2017, 02:33:40 pm »
This will be fixed in the next hot fix for v21.0.3, as well as in v22 beta3.

The Symbol Browser find tag window expects you to type something, then it will show you symbols that match the prefix (or substring) that you type.
6
ok, fair comment.  I don't use many colors and I set them up a long time ago.
7
SlickEdit 2017 v22 Beta Discussion / Re: File -> New request
« Last post by Clark on August 21, 2017, 07:56:37 am »
How about we turn on completion once you type a path? The only downside is for the first part of a relative path. Once there is a slash or a drive letter, you will get completion.
8
SlickEdit® / Re: Please shed any light on debugging Slick-C
« Last post by jwiede on August 21, 2017, 02:46:43 am »
Dennis, I understand the problem you're citing in your response.  However, there's a difference between overloaded definitions where they point at two different types, and the case where they both point at the same type (same or aliased name) only where one is "more complete" than the other. 

Like it or not, the latter it is a legitimate and rather common pattern in large, hierarchically-scoped source bases.  I do not see how the potential existence of the former pathological case explains improper handling of the latter legitimate usage case.  There are efficient tests that VS can do to differentiate the legit case from the pathological case. 

When dealing with a large source body that has such cases, we need a way to make VS follow the type aliasing deeper (or whatever is the actual cause of the failure to recognize in such cases).  If doing so generally is impractical, perhaps give us a means to provide a header file which contains the names of types which require deeper/more complex type and member tracking?  Then when VS encounters definitions involving those types it'll know it needs to follow their type and member resolution down further than normal.

I guess what I'm trying to say is that the case you described, Dennis, is pathological, while the thread's OP is referring to a completely legitimate construct, and the two can efficiently be differentiated given valid type name tracking.  In light of that, can anything be done in VS to deal better with the legitimate construct the thread OP described?  Such cases are quite common in systems/OS and similar large scale development projects, and this issue is one which gives VS fits with large source bodies.

BTW, another long-time customer here who's extremely satisfied with Slickedit!  Its functionality greatly enhances my development productivity.  That's why problems such as the one mentioned can be so frustrating -- once used to greatly-enhanced productivity from Slick's features, it is very difficult to go back to life without them.

Would very much like to know if the above issue has been fixed (or at least mitigated as described) in V22?
9
Thanks!  This one has been a real nuisance for a long time.
10
Features and/or Improvements / Re: Scroll bar overview, aka minimap
« Last post by jwiede on August 21, 2017, 02:33:15 am »
Is there work underway (or planned) to give SE a "scroll-bar code overview" as is now available in VS2015, Komodo, Ultraedit, etc. where the scroll bar itself is a micro-ptsize-rendered version of the code, to make it easier to garner an overview of the file structure, identify section/function breaks, etc.? 

If the functionality is already present, my apologies (and please provide a pointer how to enable?).  Before posting, I looked for the feature in current SE, but if present I couldn't find how to enable it.

If not present or planned already, can we please get such functionality added?  I use it all the time in VS2015, and really miss it in SE.

P.S. The feature in VS2015 is called "map mode".  For C/C++ (f.e.) the setting is in Tools->Options... (to get Options dialog), then "Text Editor -> C/C++ -> Scroll Bars -> Behavior -> 'use map mode'".

We are looking into this for a future release.  It will not make 2016, but hopefully 2017.  As always, we're very concerned about performance so it has to "be done right ". ;)

Any chance we'll see this make it into V22?
Pages: [1] 2 3 ... 10