|
Knowledge Base |
|
Knowledge Base |
(Secondary category assignments are italicized.)
See below for full list by MKB #
The following table comprises the current Montage Knowledge Base (MKB) of known problems, limitations, bugs, points of confusion, issues needing further clarification, etc. If you are reading this in a local copy of the Montage Help file, be sure to occasionally check the online Montage Knowledge Base for the latest updates to this page. New MKB Ids are assigned sequentially, with the latest additions listed at the top. (Entries are listed in descending MKB Id order.)
| MKB ID Date Created Date Updated Category ... Category |
Title Description Status |
|---|---|
| mkb00021 08/04/10 12/28/10 |
FIX: empty target after drag and drop of Shortcut to
current directory When the relative paths option is enabled, creating a Shortcut to the current directory via drag and drop produces a result whose target is blank, which is interpreted as "no target". The result should have a target of ".", i.e. a single period character, which is the correct way to specify a relative path to the current directory. Status: this bug was fixed in build 577. |
| mkb00020 08/03/10 08/09/10 |
PRB: initial use of the Ctrl+S menu hot key may not be
detected The first time you use the key combination Ctrl+S to save the current montage, it may have no effect. Pressing Ctrl+S again, however, should work, and there is no harm in issuing multiple successive save operations. There is no such problem if you use the File, Save Montage command, instead of its equivalent main menu hot key combination, Ctrl+S. Normally, when you save a montage, a brief, transient wait window message flashes by. If you don't see such a message, it may indicate that you have encountered this problem. Simply press Ctrl+S again, and the problem should not recur in the current opening of this montage. Status: this intermittent problem appears to be due to a bug in a Microsoft runtime library. The problem is easily remedied by a second key press, but it is important that you be aware of this issue to ensure that your Save Montage requests are effective. If we discover a fix, we'll certainly make it, but there is no active, ongoing effort to eliminate this minor bug, since there appears to be no simple fix. |
| mkb00019 03/25/08 08/09/10 miscellaneous |
FIX: summary of bugs and problems fixed in Montage build 559,
of 3/23/08 Montage build 559 includes the following refinements and fixes relative to the previous build 526 release:
Status: All of the preceding improvements are in build 559. See notes for build 526 regarding enhancements and fixes in that version relative to the last public release of the full, self-installing Montage setup, build 521. |
| mkb00018 01/07/06 08/09/10 |
PRB: occasional non-responsiveness to mouse clicks Under certain unusual circumstances, Montage fails to respond as it normally would to either a left or (mainly) a right mouse click. In some cases you must click again, and in other cases you need to click the other mouse button. The behavior indicates some sort of temporary confusion as to the current mouse state, due to an apparent bug in a Microsoft runtime library relating to OLE drag-and-drop. Fortunately these flaky mouse behaviors are uncommon, and the condition can be rectified simply by clicking alternately on the left and right mouse buttons. For example, after attempting to drag and drop a Shortcut onto a destination that disallows the drop (as indicated by the no-drop cursor symbol), the mouse might not respond to the next right click. Another scenario is that of dragging a dropping a Shortcut (with the left mouse button depressed) from one montage to another, and then issuing a right click in the montage that was the source of the drag, or dragging a dropping a Shortcut with the right mouse button into Windows Explorer, followed by a right click in the source montage. Prior to build 559, the source montage would become non-responsive until a left-click was issued. Another possible manifestation of this problem is that attempting to close the source montage might hang, until a left-click allows the closing to complete. These problem cases have been fixed. A different scenario known to cause similar problems, which is fairly minor but has not been fixed, is that of resizing a Montage Desktop window by using the mouse to drag its "size grip" at the lower right corner. (The problem does not occur if you resize the window by dragging one side at a time.) If you resize a montage by using its size grip, a subsequent right click in that window may be non-responsive. The simple workaround after resizing is to click the left mouse button anywhere in the montage before issuing a right click, or just follow a non-responsive right click with a left click. Status: These problems appear to be due to bugs in a Microsoft runtime library, for which we have developed some program workarounds. With the exception of the aforementioned size grip case, most problems of left/right mouse confusion and non-responsiveness have been fixed in build 559. We will continue to investigate and fix any lingering cases as they may be discovered. |
| mkb00017 01/07/06 03/24/08 |
FIX: mixed case montage names are not always preserved Prior to build 559, mixed case Montage metafile names would occasionally revert to all upper case when the montage was saved. In particular, this occurred when metafile packing reduced the montage's size. Filename case alteration doesn't affect meaning or cause errors, since Windows does not regard case as significant, but the loss of mixed case filenames can be an annoyance. Status: This problem has been fixed in build 559, which also includes a number of other refinements aimed at capturing, preserving, and displaying mixed case file names exactly as they are known to the Windows filing system. |
| mkb00016 01/04/05 02/12/06 |
INFO: issues regarding the current implementation of Montage's built-in viewers As noted elsewhere, the current implementation of Montage's built-in viewers is rather preliminary and incomplete, and for that reason viewers are not enabled by default, and not documented in detail. There is nothing fundamentally more "advanced" about internal viewers than Shortcuts to external applications, it's just that their somewhat arrested development has left Montage's built-in viewers in a rather limited and confusing state. Nevertheless, the image viewer and text viewer can be useful even in their present form, and there is good reason to expect further improvements in this area. We consider the following aspects to be the chief deficiencies in the current implementation of built-in viewers:
Status: We regard these issues as important areas for further development, because internal viewers inherently are capable of being more efficient and much more controllable than external applications, and there is clearly a great deal potential for significant added functionality. |
| mkb00015 01/04/05 02/12/06 |
INFO: limits on length of Shortcut properties With the exception of the free-form description, all of the Shortcut properties that can be entered into a textbox field are limited to a maximum length of 255 characters. This is generally more than enough room to specify any valid file or directory pathname, but there are some situations where an even longer limit might be desirable. For example, it's possible (although highly unusual) that a very long command line argument list could exceed this limit. A more likely (but still quite unusual) situation that could legitimately exceed the 255 character limit would be an extremely long URL as the target specification. One possible workaround would be to create a Montage Shortcut that points to a Windows link file, although this might require unusual settings on the Advanced properties page in order to function properly. (We aren't recommending such a kludge, just noting its potential applicability, as a last resort.) What would be better is for us to implement the necessary adjustments to the design of the Shortcut Properties dialog, to remove the length restriction by using scrollable editboxes instead of textboxes for fields where the 255 character limit might reasonably be exceeded, most notably the target (which could be a URL) and possibly the args field. In any case, the maximum length of a dynamic shortcut property would still be no more than 255 characters, because of a separate limit on the evaluation of such expressions. Another workaround that applies to very long URLs would be to employ Montage's dynamic Internet fetching mechanism. Using this approach, a separate URL link could contain a very long Internet address, but the corresponding Shortcut would refer to the local copy of the downloaded file. (If the file has not yet been downloaded, it will be retrieved automatically when needed.) This would work well when the target is a single, static image, but it may not be satisfactory for an arbitrary web page, since only the primary web page would be picked up. (Depending on how that web page was constructed, it might not be properly rendered when viewed as a local copy.) Status: Since it's unlikely that the 255 character limit would be encountered under normal usage, we have no immediate plans to address this issue, although we would reconsider the matter if enough users indicate an interest. |
| mkb00014 01/04/05 08/09/10 |
PRB: drag-and-drop "Move" into Explorer actually
performs a "Copy" While it may appear that you have the choice of either moving or copying a Shortcut when dragging out of Montage into Windows Explorer, e.g. to the Windows desktop, in fact the only operation currently supported is to copy the Shortcut. I.e. if you right-click drag-and-drop, and then choose Move from the context menu, the original Shortcut is copied, but not deleted as one might expect. Because of what may be a bug in a Microsoft runtime library, it is not possible for Montage to determine whether the user's choice was to Move or Cancel in such cases. (The Move operation is supported in the context of dragging and dropping within a montage, and Move is not currently presented as a choice when dragging and dropping from one montage to another.) The problem is minor (albeit misleading and somewhat inconvenient), since you can simply delete a Shortcut after copying it to achieve the same effect as a Move. Status: We will continue looking for a better solution to this issue. |
| mkb00013 07/28/04 02/12/06 |
INFO: how Montage determines the sequence of state restoration steps When you restore a previous view by opening a montage or using the Restore View command, each previously open Shortcut is launched in a certain sequence. That sequence is determined by the order in which those Shortcuts were last selected, which is not necessarily the same as the order of activating the target windows associated with those Shortcuts, since there are many ways to activate a window besides going through its Shortcut. You can deliberately force a particular launch sequence simply by clicking once on each Shortcut in the desired order. Generally the order of launching will also determine the external target window stacking sequence (z-order), i.e. the layering as to which window is in front of which other windows, which window is foremost, etc. However, because of unpredictable timing considerations, the window stacking sequence for external applications tends not to be perfectly reproducible. (The stacking sequence of built-in viewers, however, always is preserved.) Status: We may add some features to provide more explicit control over sequencing, but there are no imminent plans in this area. |
| mkb00012 07/24/04 08/09/10 miscellaneous |
FIX: summary of bugs and problems fixed in Montage build 517, of 9/4/04 Montage build 517 fixes the following problems that existed in the previous release, build 373:
Status: All of the preceding bugs have been fixed in build 517. |
| mkb00011 01/13/03 08/09/10 |
INFO: avoiding Montage installation problems on very old computers If you have an old Windows 95 machine without Internet Explorer (IE), or with a very old version (IE 3.x), the quick-install procedure may not work, making it necessary to use the standard setup. However, the standard setup will not finish cleanly if it is unable to install VFP's HTML Help support, which has certain prerequisites. It is recommended that you have installed a reasonably recent version of Internet Explorer (IE 4.0 or later) before installing Montage, in which case you should not encounter any unusual problems. If you do choose to go ahead and install Montage without having IE 4.0 or later, and you disregard the setup dialog(s) warning that certain HTML Help-related files can't be properly registered, you may actually obtain a usable installation of Montage, minus support for Help. However, the setup will indicate that it failed, and you may be unable to use the Control Panel's Add/Remove Programs facility to uninstall Montage. (You could still do a manual uninstallation, of course.) Status: Since few people are likely to encounter such problems, we don't expect to focus much more attention on this issue. However, we are making every effort to provide a reasonable level of support for all versions of Windows, dating back to the original release of Windows 95. |
| mkb00010 01/13/03 02/12/06 |
PRB: applications that launch multiple windows may be mis-detected Montage works best with well-behaved applications that open a single new, top-level window when they are launched. If an application opens multiple windows when it is started, this could lead to mis-detection, where Montage mistakenly associates the wrong external window with the Shortcut that was invoked. As of build 517, Montage's general detection logic and application intelligence have been improved, reducing the likelihood of encountering mis-detections, especially in the case of nested montages. (Previous restrictions against leaving open Shortcuts in a child montage have been greatly relaxed, but there are still potential cases of "weak" detection that could cause problems. If you run into such a case, avoid leaving the offending Shortcut open when you close the montage that contains it.) For cases where Montage fails to detect the proper window, Advanced settings may allow you to improve matters by manually overriding the default detection logic. Status: This problem has been alleviated by changes in build 517, and we will continue making application-specific refinements as necessary. |
| mkb00009 01/13/03 08/09/10 |
INFO: application characteristics that are saved and restored by Montage Ideally, every aspect of an application that the user can alter should be something that Montage can save and restore, but in practice this is too difficult to accomplish. At a minimum, Montage remembers the most general characteristics: which applications it launched, whether they were left open, and the last size, position, and zoom state of their main windows. (Also see INFO: how Montage determines the sequence of state restoration steps.) Beyond that, which additional settings Montage recognizes and remembers is application-dependent. For the particular case of Shell Explorer windows, Montage also saves and restores the TreeView mode and view mode. Additional Explorer attributes one might wish to preserve include, for example, the directory to which the Explorer window was navigated (after starting from an initial location, which is restored), "details" mode column widths and sort order, the current selection of files within the target folder, the position of the divider in split-paned mode, etc. These properties are not currently saved and restored by Montage, but Windows' use of the registry covers some of them, to some extent. Status: Build 517 added general support for saving and restoring zoom states. We expect to add further aspects of application intelligence on an ongoing basis, guided by user feedback as to applications and properties of greatest interest. |
| mkb00008 12/20/02 08/09/10 |
INFO: integral Montage Help facilities may not work unless standard (full) setup is used If you performed a quick-installation, you probably will not be able to use Montage's integrated Help features unless you perform some additional steps. Normally one should be able to access context-sensitive help by pressing F1, using What's This help, or through various menus. However, unless the supporting VFP runtime Help libraries have been properly installed, those integral Help features will not work, although no error occurs. (Help menu commands should be visibly disabled when the Montage Help file is missing, but the Help commands simply don't function if the required runtime is not installed.) For Montage Help to function properly you not only need to have HTML Help installed, but also you need to have installed the Visual FoxPro (VFP) runtime Help support files, FOXHHELP.EXE and FOXHHELPPS.DLL. You can easily tell if HTML Help is properly installed by opening the Montage Help file, MONTAGE.CHM, directly through Windows Explorer. If that works, but F1 Help doesn't work under Montage, you can still create and use a Shortcut to MONTAGE.CHM, but only a proper installation of the VFP runtime Help support libraries will allow you to use Montage's context-sensitive Help and related menu commands. If HTML Help is installed, running the full, standard Montage setup should take care of properly installing the required VFP Help support files. Status: Since manual setup of the VFP Help runtime is quite easy, and there are other simple ways to get to Montage Help, this should not present any serious problems, but we plan to continue streamlining and automating installation procedures. |
| mkb00007 12/20/02 08/09/10 |
FIX: OLE IDispatch error after dragging and dropping a URL from IE into Montage Prior to build 559, the following scenario would trigger an error (VFP Error #: 1429, OLE IDispatch exception code 0):
Before you could drop the Shortcut to the Windows desktop (i.e. while in mid-drag), the aforementioned error would strike. This could leave Montage in a screwy state, with the mouse cursor still indicating a drag-and-drop in progress, and the error dialog not responding to mouse clicks. Under Windows 2000 and XP, the Windows taskbar could be used to regain control of Montage, but Windows 95 systems required a Ctrl+Alt+Del to kill the Montage window. There was no such problem if the montage was closed and reopened: this bug only occurred immediately after a Shortcut had been created by dropping a URL into a Montage Desktop window, i.e. in the same opening. An even simpler workaround, short of closing and reopening the montage, was simply to Save View and immediately Restore View after dragging one or more hyperlinks into a montage. Note that this bug did not affect the more common usage of dragging and dropping files and folders, or links (.LNK or .URL files) from Windows Explorer into Montage. Status: This bug has been fixed in build 559. |
| mkb00006 12/19/02 02/12/06 |
FIX: occasional C00000FD errors on editing Shortcut title via Properties dialog When entering text into the Title textbox of the Shortcut Properties dialog, one might occasionally (infrequently) encounter errors (Exception code=C00000FD) causing Montage to terminate instantly, without its normal, clean shutdown. This bug did not affect the direct editing of captions by clicking on a selected Shortcut. Status: This bug was fixed in build 517. (An obscure side-effect of the fix is that multiple consecutive spaces are now automatically converted to single spaces in Shortcut titles.) |
| mkb00005 12/16/02 08/09/10 |
INFO: current limitations relating to Windows special folders Special Windows Shell objects, like the My Computer icon on your desktop, My Network/Network Neighborhood, Control Panel, etc. can be tricky to set up as Montage Shortcuts. In most cases Montage refuses to drag-and-drop these from Windows Explorer into a Montage Desktop window. If you create a Windows shortcut (i.e. a link) to such a special folder, Montage may allow you to drag and drop it into its Desktop window, but the resulting Shortcut will have a blank target and it won't open the intended special folder. In some, if not all cases it may be possible to achieve the desired result by setting the Shortcut properties manually, but this requires knowing the proper program to invoke, and what arguments to pass to it. Status: Montage build 517 included some samples illustrating the use of CLSIDs, which are particularly useful for special folders. As of Montage build 559, special folder Shortcuts can be dragged and dropped between montages, but still not directly from Explorer into a montage. We are continuing to look into ways of improving Montage's support for Windows special folders, as well as providing a larger variety of samples. |
| mkb00004 12/16/02 12/31/10 |
PRB: on some systems, Montage may not detect and restore Explorer's Folders TreeView mode Montage has the ability to detect whether a Shell Explorer window is split-paned, with a collapsible tree of Folders at the left. Under some versions of Windows and Internet Explorer this feature may not work. In Windows 98 and versions through Windows XP, Windows Explorer allows the user to dynamically switch the TreeView (folder navigation) pane on or off, and Montage is supposed to remember which state you left that Explorer window in, so it can be automatically restored. Similarly, Internet Explorer (IE) up to version 6 supported a "Folders view" mode, which Montage could save and restore. Newer versions of IE, however, have discontinued support of this feature. You can tell right away if Montage is properly recognizing the TreeView mode by launching an Explorer Shortcut and seeing if its icon changes as you toggle the Explorer window's folder navigation pane on and off. (Even if Montage is not detecting and restoring the TreeView mode, you may still be able to manually launch into this mode via the Shortcut's Explore Target command.) Montage's support for TreeView mode is inherently limited by version-dependent restrictions in Windows and IE. Some related Montage bugs were fixed in build 517 (see MKB00012), but these fixes only pertain to Windows XP, IE6, and earlier versions. Status: Montage will not support TreeView mode beyond version 6 of Internet Explorer, since Microsoft has discontinued this feature. While newer versions of Windows Explorer (beyond Windows XP) do support a somewhat similar capability, it is sufficiently different to be incompatible with Montage. We do not plan to revive Montage support of TreeView mode beyond Windows XP. |
| mkb00003 12/16/02 02/12/06 |
PRB: failure to recognize that some applications "open" by activating an existing window When Montage launches an application, it waits for a new window associated with a new instance of that application. Some programs, however, will activate an already open window instead of creating a new one, and Montage may time out waiting for the new window to appear. Montage works fine when it opens the first instance of such an application, but it may not understand the special case of subsequent pass-offs, which simply activate a previously open window. The manifestation of this problem is that a wait window message is displayed, indicating that Montage is awaiting the appearance of the target window, when in fact the launch completed by activating a pre-existing window. You can press the Esc key to cancel this opening, but Montage would then fail to realize that this Shortcut is open. (The global Wait Limit setting, governs whether Montage will wait indefinitely, unless you Escape, or time out after a specified number of seconds.) As of build 517, Montage generally detects pass-off cases by making use of process IDs to automatically recognize that there is no point in waiting for a new window. In addition, Montage knows about a number of exceptional cases, e.g. various Microsoft applications that require special detection logic. Advanced property settings may also be used to assist Montage in recognizing any pass-off situations that it fails to detect automatically. A normal pass-off simply activates the existing target window, leaving the Shortcut un-highlighted, because this Montage is not the real parent of this application instance. However, for certain pass-off cases, Montage supports an auto-detection mode indicating its recognition of the special connection between this Shortcut and its pre-existing target window. Status: Problems with detection of pass-offs have been largely resolved in build 517. Further knowledge about special case exceptions will be incorporated into Montage's built-in application intelligence, as the need arises. |
| mkb00002 12/16/02 02/12/06 |
PRB: application startup dialogs and splash screens may interfere with proper detection When opening a Shortcut, usually Montage will correctly recognize that a preliminary popup dialog is not really the main application window, but in other cases it may mistakenly treat the dialog or splash screen as the window in question. In such cases cases of mis-detection, Montage behaves as though the application has been closed when the transient dialog is closed, and consequently fails to realize that the application is still running in a different window (its Shortcut should be highlighted, but isn't). The likelihood of encountering these problems has been greatly reduced by changes in build 517, which does a better job by automatically ignoring preliminary popup dialogs by default, with certain deliberate exceptions. Also there is now a page of Advanced launching and detection options, which can be used to manually override Montage's default detection logic. The remaining remedies are to find a suitable command line option to suppress the offending dialog, or simply avoid launching this particular application through Montage. Status: This problem has been largely resolved in build 517. Further knowledge about special case exceptions will be incorporated into Montage's built-in application intelligence, as the need arises. |
| mkb00001 12/16/02 03/23/08 |
FIX: the size of a Montage metafile grows too large after repeated use As of build 517, Montage no longer suffers from progressive metafile bloating, because it now supports an automatic metafile packing option (enabled by default), as well as an explicit Pack command. The PACK operation recovers free space and keeps the size of a montage small and stable. Prior versions of Montage did not automatically pack the metafile, so it would grow every time you saved the view, and no explicit Pack command was provided. The only available remedy was to issue a Save View As... command, causing the resulting montage to be packed in a roundabout way. Alternatively, with the Visual FoxPro Development System, one could open the .MO3 file as a table and issue a PACK and a REINDEX command. (An advanced user could actually do this directly through Montage, using its Command Processor, but that approach would not be recommended.) Status: This problem was fixed in build 517. Further changes to reduce metafile size were introduced in build 559, including the Save Command Processors option and the Zap command. |
|
Next: Version History |
||
|
|
||
|
Montage Help page, last edited:
12/31/10 16:20
|
