• Dear Cerberus X User!

    As we prepare to transition the forum ownership from Mike to Phil (TripleHead GmbH), we need your explicit consent to transfer your user data in accordance with our amended Terms and Rules in order to be compliant with data protection laws.

    Important: If you accept the amended Terms and Rules, you agree to the transfer of your user data to the future forum owner!

    Please read the new Terms and Rules below, check the box to agree, and click "Accept" to continue enjoying your Cerberus X Forum experience. The deadline for consent is April 5, 2024.

    Do not accept the amended Terms and Rules if you do not wish your personal data to be transferred to the future forum owner!

    Accepting ensures:

    - Continued access to your account with a short break for the actual transfer.

    - Retention of your data under the same terms.

    Without consent:

    - You don't have further access to your forum user account.

    - Your account and personal data will be deleted after April 5, 2024.

    - Public posts remain, but usernames indicating real identity will be anonymized. If you disagree with a fictitious name you have the option to contact us so we can find a name that is acceptable to you.

    We hope to keep you in our community and see you on the forum soon!

    All the best

    Your Cerberus X Team

Fixed TED opens new edit tab for file that is already open on errors and debug stop.

dawlane

Well-known member
CX Code Contributor
Tutorial Author
Joined
Jun 21, 2017
Messages
1,146
TED has an intermittent habit of opening a new edit tab for a file that is already open in the editor when a code error or debug stop is detected.

I suspect that the problem lies within MainWindow:: openFile and with it calling MainWindow::editorWithPath.

This is on Linux and I will have to test the others operating systems.
 
OK looks like it's not a bug but a system path error with how a system is set up. System links are not being followed or are not taken into account in TED. Why I never noticed this before is beyond me, it shows the file path in the window title.:oops:

Example: You have two hard drives installed. Hard drive one is has the operating system and the user home directories, hard drive two holds your development files. Hard drive two is mounted in /mnt under the directory name dev, but you have a link in your home directory to this directory, so the paths would be /mnt/dev and /home/user/dev. This mean that if you open a file in TED via the home directory link (/home/user/dev) the path stored is different from what is being returned by transcc (/mnt/dev).

May be able to fix this some how with using QFileInfo::canonicalFilePath().
 
Last edited:
More like an over-site on Mark's side. I take that when TED was written Mark didn't give much thought to how file paths could be handled on a system, after all, system links are not that common on your average Windows users system. So it could be mark down as a bug.

I'm currently having a look to see if I can find a suitable solution of converting the paths where QFile are used.
 
Well the fix on Linux is simple enough.
In file mainwindow.cpp add
Code:
path = QFileInfo(path).canonicalFilePath();
in both the member functions before any method that sends a path to the class CodeEditor:

Code:
QWidget *newFile( const QString &path );
after the file.close(); and before the if statement.

Code:
QWidget *openFile( const QString &path,bool addToRecent );
after the if( path.isEmpty) block and before CodeEditor *editor=editorWithPath( path );

I haven't test this with Windows or OS X yet. Having trouble with getting a version of Qt that supports Webkit working.
 
Actually I used 5.5.1 because this version was the latest using webkit stuff.
 
Just checked with the current version of Ted on Windows: QT_VERSION 0x050501, so 5.5.1 it is.
It's taken me longer to install Qt on Windows than for either Linux or OS X. And by the looks of it symbolic links are behaving normally without the use of canonicalFilePath, which has no affect. So Windows API's must be resolving links.

Next test OS X
 
So far all OS's appear to be working correctly with file handling, apart from opening a directory alias in OS X as a project. Must have something to do with this
Code:
QFileDialog::dontResolveSymlinks
flag being passed in MainWindow onBuildAddProject(), as removing it allows an alias to be resolved correctly instead of loading it into the code editor. Whether this removal causes problems with the other OS's has to be checked.
 
Last edited:
@dawlane, is this still an issue in the official version?

Btw. could you please produce a distribution of 2018-12-30?
 
New Linux 64 build of Cerberus-2018-12-30 compiled on Linux Mint 18.3 (Sylvia).

is this still an issue in the official version?
Yes the bug is still in there. I will have to have a look from one of my old ted files to see where I originally made the changes to fix it and post a patch file.
 
OK instead of a patch file a quick fix that so far seems to work.

In the file mainwindow.cpp:

In method implementation (around line 551)
Code:
QWidget *MainWindow::newFile( const QString &cpath )
change
Code:
file.close();

    if( CodeEditor *editor=editorWithPath( path ) ) closeFile( editor );
to
Code:
    file.close();

/* DAWLANE LINUX SYSLINK PATH FIX
* If symbolic links are use, the IDE will try to open a new editor on an error.
* This fix sets the path to the full path of the actual target file.
*/
#ifdef Q_OS_LINUX
    path = QFileInfo(path).canonicalFilePath();
#endif

    if( CodeEditor *editor=editorWithPath( path ) ) closeFile( editor );

In the method implementation (around line 665)
Code:
QWidget *MainWindow::openFile( const QString &cpath,bool addToRecent )
change
Code:
    if (isDocFile(path)) {
        showDoc(path);
        return nullptr;
    }

    CodeEditor *editor=editorWithPath( path );
to
Code:
    if (isDocFile(path)) {
        showDoc(path);
        return nullptr;
    }

/* DAWLANE LINUX SYSLINK PATH FIX
* If symbolic links are use, the IDE will try to open a new editor on an error.
* This fix sets the path to the full path of the actual target file.
*/
#ifdef Q_OS_LINUX
    path = QFileInfo(path).canonicalFilePath();
#endif

    CodeEditor *editor=editorWithPath( path );

In the method implementation (around line 589)
Code:
QWidget *MainWindow::newFileTemplate( const QString &cpath )
change
Code:
if( !file.open( QIODevice::ReadOnly ) ){
        QMessageBox::warning( this,"New file","Failed to create new file from template: "+path );
        return nullptr;
    }

    file.close();

    if( CodeEditor *editor=editorWithPath( path ) ) closeFile( editor );
to
Code:
    if( !file.open( QIODevice::ReadOnly ) ){
        QMessageBox::warning( this,"New file","Failed to create new file from template: "+path );
        return nullptr;
    }

    file.close();
/* DAWLANE LINUX SYSLINK PATH FIX
* If symbolic links are use, the IDE will try to open a new editor on an error.
* This fix sets the path to the full path of the actual target file.
*/
#ifdef Q_OS_LINUX
    path = QFileInfo(path).canonicalFilePath();
#endif
    if( CodeEditor *editor=editorWithPath( path ) ) closeFile( editor );
 
Thank you. I asked because on Windows I never saw this behavior.
 
I asked because on Windows I never saw this behavior.
Links are hardly ever used on Windows with such things needing elevated privileges to create them. But Linux and Mac OSX (to a certain point) allow user created links. The last time I messed around with Ted and Mac OSX folder alias links, Ted tried to open the folder alias for editing in the editor.
I think that QDirIterator::FollowSymlinks had to be set, but if I recall care had to be taken with alias to files as Qt of the day could remove the actual file and not the alias.
 
Last edited:
Back
Top Bottom