An open source project scheduling tool for Windows, Macintosh, and Linux.

GanttPV Quirks

Much of the power and simplicity of GanttPV comes from taking a different path. But sometimes that path results in odd behaviors that can surprise the unwary. This page offers a catalog of quirks that every GanttPV user should know about. Be sure to email us if you have one to add to this list.

Why do these quirks exist?

Most of these quirks are the flip side of a GanttPV strength. See the print command for an example. Others exist because certain expected features haven't been implemented yet, usually because other important features were implemented instead. On to the quirks!

  • Where is the print command?
  • Why doesn't my .ganttpv file open when I double click it?
  • Why is (fill in the blank) feature implemented as a script?
  • What do the install scripts do?
  • The 'Insert Row' command didn't insert the new row where I expected it.
  • Why doesn't GanttPV just remove 'deleted' records?
  • The bars aren't moving when I change durations or dependencies. What's wrong?
  • Why don't the print and HTML export scripts display (fill in the blank) properly?
  • Where is the print command?

    The print command is on the scripts menu. The developers have many more ideas that they would like to include in printing and it is faster and safer to offer printing updates as scripts. It also allows interested, technically oriented users to customize the reports much more easily than otherwise. Still, if you don't know where to find the print command it can be annoying.

    Why doesn't my .ganttpv file open when I double click it?

    On MS Windows, the first time you double click an .ganttpv file you will have to tell your computer to use GanttPV. From then on double clicking will work. The GanttPV install script for windows doesn't do this for you. (Are you interested in contributing a fix for this?)

    On the Macintosh, double-click opening of .ganttpv files works just fine. (Thanks, Alexander!)

    Why is (fill in the blank) feature implemented as a script?

    New features are first implemented as scripts whenever possible. Good ideas always need to be tested against the surprises of reality. Implementing ideas as scripts allows developers to improve and simplify the ideas before accepting them into the core of GanttPV. There are other practical benefits: scripts are faster to write and easier to test than additions to the main program; interested users can learn from the scripts and modify them to meet needs the developers hadn't anticipated; developers can correct and distribute updates to scripts more frequently that updates to the main program.

    What do the install scripts do?

    Let's look at an example: "Install Week Gantt Time Scale" is a script that adds a new option to GanttPV. As described in the tutorial, when you click the "Insert Column" button a list of available column types pops open for you selection. The "install" script adds a new option, "Week/Gantt" to that list. Two options really. It also adds a "blank" column that is useful when you want to put a spacer between two different time scales. (It is hard to see but can be selected by clicking below the Week/Gantt line.)

    The other "install" type scripts work similarly, they add new report or column types to the pop up choices. Some define new data tables.

    When you create a new file, GanttPV automatically installs the standard report and column types into your file. When you use an "install" script, you add more report or column types. The reason the report and column types are installed in your data file and not into the GanttPV program is so that when you share the file with someone else all of the necessary type definitions will be there.

    The 'Insert Row' command didn't insert the new row where I expected it. (Fixed in v0.4)

    To insert an new item in the middle of the list, you select a row and click the "Insert Row" button. Normally the new row is inserted above the row you selected. Sometimes, due to a small bug in GanttPV the new row will be inserted above the location you specify. This is because GanttPV is being thrown off by "deleted rows" when it is calculating the position. The work around is this: before you delete a row change its sort field value to some high value, like "zzz" or "2007-12-31" or 999. (If you forget, you can change them later after making them visible with the "Show Hidden" toggle button.) You can also use the "Purge" script to remove the deleted records. (As always, make a back up copy of your file before you run the purge script. Always verify that the script had the effect you intended.)

    Why doesn't GanttPV just remove 'deleted' records?

    "Deleted" records are kept, but hidden. You can toggle visibility of deleted records by using the "Show Hidden" button. If you select a "deleted" row and click the "Delete Row" button, the row is "un-deleted" (but its child records may not be).

    The primary reason was to simplify the "Undo/Redo" logic. By using a "deleted" flag the program doesn't have to remember whether to re-insert or re-delete rows of data. The second reason was to better support future multi-user features. It is much easier to notify other users that a record has been "deleted" if you keep the record around while you notify everyone.

    The bars aren't moving when I change durations or dependencies. What's wrong?

    You might have defined a loop in the dependencies. GanttPV will stop calculating new start dates as soon as it runs into the loop. GanttPV sees it as an inability to find another task whose prerequisites have all been processed.

    To locate the error try temporarily changing the duration of the first task to some large number. Then examine which of the follow on tasks didn't shift. The first unshifted task is part of the loop. Review the remaining tasks to find out which is in error.

    Why don't the print and HTML export scripts display (fill in the blank) properly?

    There are three main reasons why this can happen:

    • When a feature is added to GanttPV the developers decide whether to release it or wait until the print and HTML export scripts catch up. If the feature has value without them, they release it immediately.
    • Sometimes they need feedback on the use of a feature before they implement the print and HTML versions. It is more efficient if they wait for the improvements before they invest the effort. They want to get it right before They build on it.
    • Sometimes the print or html medium isn't suited to display it adequately.

     ;