Recent Posts

Pages: [1] 2 3 ... 10

SlickEdit 2023 v28 Beta Discussion / Re: Relative project member file calc fails when "/mnt" is only common component

« Last post by Clark on Today at 10:06:33 pm »

Fixed for beta 4. Thanks for finding this. This does look like an old bug.

relative("/mnt/whatever","/mnt/vbox")==/whatever --- definitely wrong

relative ("/a", "/b")==/whatever -- This is sort of ok but will change to ../whatever in beta 4.

Here's how you know for certain whether relative is returning a bad value.

The following has to work:

absolute(relative(absolute-filename,toDirectory),toDirectory)==absolute-filename

This is how you know relative("/mnt/whatever","/mnt/vbox")==/whatever is WRONG. The bug is that it's using some logic which can only be applied on Windows but not Unix/Linux/macOS.

SlickEdit® / typed characters are appearing out of order

« Last post by Chris Nisbet on Today at 10:04:08 pm »

I've started seeing a problem where characters I enter using the keyboard are getting entered out of order. I wouldn't swear to it, but I think it started happening after I upgraded to 27.0.2.0. What happens is that some characters show on the screen as expected, but then the screen will freeze for a short period of time and then the last few characters entered will turn up in the incorrect order.
e.g. this is the what turned up on the screen after entering the characters "turnkey".

turekny

The problem doesn't happen all the time - I can enter quite a few characters and not see the problem, but then I'll notice that some characters turn up in the incorrect order. For a while I thought it might be operator error, but it isn't. The out-of-order issue seems to coincide with this 'stickyness' I experience with the update of the edit buffer - the display will stop updating for a short time (< 1 second) and then the last few characters entered will/might show up in the incorrect order. If I type slowly, the problem doesn't occur, but what I will see is that even a single character will take some time to turn up in the buffer window.

In terms of buffers open, it doesn't seem to matter too much - I can reproduce the problem with just a single 500 line .c file open.

Anyway, I'm wondering if there are some settings I can adjust to reduce the likelihood of this happening? I'm guessing that maybe something like autocomplete or syntax highlighting might be involved somehow, but I don't know what the recommended/default settings might be.

Any assistance would be greatly appreciated.

Program Information:
SlickEdit Pro 2022 (v27.0.2.0 64-bit Qt4)

Serial number: VLX930448
Licensed number of users: Single user
License file: /home/chris/slickedit-pro2022/bin/slickedit.lic

Build Date: April 25, 2023 (State file: August 7, 2023)
Emulation: CUA

OS: Linux
OS Version: Ubuntu 23.04
Kernel Level: 6.2.0-33-generic
Build Version: #33-Ubuntu SMP PREEMPT_DYNAMIC Tue Sep 5 14:49:19 UTC 2023
Processor Architecture: x86_64

X Server Vendor: The X.Org Foundation
Window Manager: GNOME Shell
Display manager: /usr/sbin/gdm3

SlickEdit Pro 2022 (v27.0.2.0 64-bit Qt4)

Serial number: VLX930448
Licensed number of users: Single user
License file: /home/chris/slickedit-pro2022/bin/slickedit.lic

Build Date: April 25, 2023 (State file: August 7, 2023)
Emulation: CUA

OS: Linux
OS Version: Ubuntu 23.04
Kernel Level: 6.2.0-33-generic
Build Version: #33-Ubuntu SMP PREEMPT_DYNAMIC Tue Sep 5 14:49:19 UTC 2023
Processor Architecture: x86_64

X Server Vendor: The X.Org Foundation
Window Manager: GNOME Shell
Display manager: /usr/sbin/gdm3

Memory: 74% Load, 8502MB/11351MB Virtual
Shell Information: "/home/chris/slickedit-pro2022/bin/secsh" -i
Screen Size: 3840 x 2160

Project Type: Gnuc
Language: .c (C/C++)
Encoding: UTF-8, no signature

Installation Directory: /home/chris/slickedit-pro2022/
Configuration Directory: /home/chris/.slickedit/27.0.2/
Migrated from: /home/chris/.slickedit/26.0.3/
Spill File: /tmp/$slk.chris.1667411

Hotfixes:
/home/chris/.slickedit/27.0.2/hotfixes/hotfix_se2702_11_cumulative.zip Revision: 11 (currently loaded)
/home/chris/.slickedit/27.0.2/hotfixes/hotfix_se2702_5_cumulative.zip Revision: 5 (superseded)

SlickEdit 2023 v28 Beta Discussion / Re: Javadoc Preview Ignores paragraph separators

« Last post by Dennis on Today at 09:48:06 pm »

I added some code to align the comment descriptions. However, it just takes a guess at how much space to allow, so if there is a particularly long named parameter, it's going to free flow.

SlickEdit 2023 v28 Beta Discussion / Slickedit forgets where focus is on model dialog

« Last post by astromme on Today at 04:46:46 pm »

SlickEdit Pro 2023 (v28.0.0.3 64-bit Qt5) on Ubuntu 22.04.3 LTS

I make a change to a file without saving
I undo those changes, then undo once more
The modal dialog that says "You are about to undo past previous save. Continue?" appears
I dismiss it with escape
The cursor becomes active in a pane in a different window than the one I was editing

SlickEdit 2023 v28 Beta Discussion / Re: Git status indicators on Buffers tab

« Last post by Dan on Today at 01:08:06 pm »

I'm sorry for the inconvenience. Let me double check things.

SlickEdit 2023 v28 Beta Discussion / Re: Git status indicators on Buffers tab

« Last post by curtiswren on Today at 12:23:26 pm »

Still seeing this issue on beta 3.

Thanks

SlickEdit 2023 v28 Beta Discussion / Re: Relative project member file calc fails when "/mnt" is only common component

« Last post by os2bird on Today at 08:44:59 am »

Seems the root of the problem is the relative() function (again linux/amd64 host, beta3):

Code: [Select]

say("good: " :+ relative("/mnt/scratch/whatever",  "/mnt/scratch/vbox"));
say("bad1: " :+ relative("/mnt/whatever",  "/mnt/vbox"));
say("bad2: " :+ relative("/whatever",  "/vbox"));

Results in:
good: ../whatever bad1: /whatever bad2: /whatever

All the paths returned should be the same ("../whatever").

SlickEdit 2023 v28 Beta Discussion / Relative project member file calc fails when "/mnt" is only common component

« Last post by os2bird on Today at 12:58:05 am »

This could be an older issue, but it happens with beta 1 and beta 3 on linux.

I'm creating a project "MacMiniM1-VMM.vpj" (type 'Other') in a new "/mnt/scratch/vbox/slickedit/test1/" directory. However, the source tree I add to the project is in a very different place: "/mnt/macmini-m1/scratch/vbox/svn/trunk/src/VBox/VMM/". When project + workspace is created and opened, it's empty. Looking into the "Project Properties" it lists "/macmini-m1/scratch/vbox/svn/trunk/src/VBox/VMM/*" in the project files list. The "/mnt" part of the path is gone.

If I try correct the issue by the "Remove All" and "Add Tree" buttons, I navigate to the directory and add it again. Same thing, no leading "/mnt/". Doesn't matter what I add under /mnt/, as long as it isn't in "/mnt/scratch". However, if I for instance try add "/mnt/scratch/src/bash/bash-2.0/" (using the "Add Tree" button), it works and shows up as "../../../src/bash/bash-2.0/*.*".

My guess is that this is an issue with the relative path calculation, where it somehow doesn't add the "../../../.." prefix.

- bird

P.S. the "Properties..." button in the "Project Properties" dialog hangs / locks slickedit here on my linux box and I have to do a "killall -9 vs_exe" to get rid of it.

SlickEdit 2023 v28 Beta Discussion / Saving file afer a "fake" changes leaves lines red (Show modified lines)

« Last post by astromme on September 21, 2023, 10:54:17 pm »

My issue title is horrible.

I add a space to the end of a line and see a red block in the left column, I assume for "Show Modified Lines".
When I save it when Options->File Options->Save->Strip trailing spaces is set to "Strip all trailing spaces", the block remains red. Nothing really changed, but it's marked as if it did.

SlickEdit 2023 v28 Beta Discussion / Re: Javadoc Preview Ignores paragraph separators

« Last post by Johnco3 on September 21, 2023, 09:59:37 pm »

Dennis, I tried the support for @param[in] for example and with no spaces between the param and the oppening square bracket, the color coding for the param is lost. I've always put the [in,out], [in], [out] at the same indentation level as the first comment for the parameter - perhaps I was incorrect and I'm not sure that the doxygen guidelines correctly. I am not sure that the spec is very accurate, as it seems to specify a space between the param and the opening '[', which does not match their example (if their example used this space the color coding to the '@param' text would not be broken).
Also the doxygen example for 'dir' is well formatted, as a comment header (it is missing the closing comment '*/').

Code: [Select]

/*!
   Copies bytes from a source memory area to a destination memory area,
   where both areas may not overlap.
   @param[out] dest The memory area to copy to.
   @param[in]  src  The memory area to copy from.
   @param[in]  n    The number of bytes to copy
  /
void memcpy(void *dest, const void *src, size_t n);

With this example (fixed up with the missing */) The latest beta 3 shows the attached screen shot, which is definitely not very useful.

As far as something that would look awesome in the preview area, I think aligning the '-' separators on the same column for each parameter would look amazing. Naturally line wrap would need to be indented 2 spaces after the leading - to make things look good. Alternative food for thought might be to consider using a separate color for the [in,out,reference etc.]

Pages: [1] 2 3 ... 10