Bug 249631 - Calling MarbleWidget::removePlacemarkKey() does nothing on MS Windows
Summary: Calling MarbleWidget::removePlacemarkKey() does nothing on MS Windows
Status: RESOLVED FIXED
Alias: None
Product: marble
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Microsoft Windows
: NOR normal
Target Milestone: 1.0 (KDE 4.6)
Assignee: marble-bugs
URL:
Keywords: investigated, triaged
Depends on:
Blocks:
 
Reported: 2010-08-31 15:19 UTC by Volker Lanz
Modified: 2018-09-19 14:42 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Volker Lanz 2010-08-31 15:19:00 UTC
Version:           unspecified (using Devel) 
OS:                MS Windows

In Workout I add a kml file to the marble widget each time the user selected a different activity and remove the previous one. The code looks a bit like this:

-----

QFile tempFile(tempFileName()); // tempFileName() is a static method

marbleWidget->removePlacemarkKey(tempFileName());

if (!tempFile.open(QIODevice::WriteOnly|QIODevice::Truncate))
    return;

// ... create new temp file based on selected activity ...

tempFile.close();
marbleWidget->addPlacemarkFile(tempFileName());

-----

This works fine on Linux, but the old map is never removed from the MarbleWidget on Windows. Instead, both the old and new one are being shown.


Reproducible: Always
Comment 1 Volker Lanz 2010-08-31 22:14:39 UTC
To clarify, this is tempFileName():

-----
QString MapDockWidget::tempFileName() const
{
    return QString("%1%2workout-marble-widget-%3.kml")
        .arg(QDir::tempPath())
        .arg(QDir::separator())
        .arg(QCoreApplication::applicationPid());
}
-----
Comment 2 Thibaut Gridel 2011-01-10 23:49:09 UTC
Hi, could you please test after trunk revision 1213564?
I simplified some name looking code for placemark file keys, which may fix that problem.
Comment 3 Andrew Crouthamel 2018-09-19 14:42:22 UTC
This bug has had its resolution changed, but accidentally has been left in NEEDSINFO status. I am thus closing this bug and setting the status as RESOLVED to reflect the resolution change.