Jump to content

JoelS

Member
  • Posts

    72
  • Joined

  • Last visited

Posts posted by JoelS

  1. I have document (palette) scripts that reference a set of includes in a folder along with VW, all ending in .px (e.g. FileName.px) and are so referenced in the document scripts, with the right path. Everything works and the include files reside nowhere else.

    However, when I encrypt/lock/protect the scripts and then move the includes, the scripts fail (also after an application restart). Restoring the folder restores correct operation.

    The documentation states that the code is copied from the include to the encryped script and the includes, untouched, are no longer required. This does not appear to be the case here.

    The encryped document scripts really are 'locked' - they can no longer be edited. The include files are untouched.

    Why am I seeing this behaviour and how can I remove the dependence on the includes?

    TIA

    Joel.

    Mac OS 9.2.2, VW11.0

  2. Delmer and Travis,

    Thanks for kicking this around - looks like some kind of procedural solution is required.

    In any DB it's normal to expect some basic level of access control - I'd like to write-protect layers for some users too in some cases so they could see and snap but not modify. Perhaps some of these functions will appear in future releases?

    Thanks,

    Joel.

  3. Delmer,

    If user A sends a file to user B who makes their specific changes to objects with attached records as part of a group effort and then returns it, how are you to determine in which respects the file has changed so as to screen out data fields that should not have been modified?

    User A could split the RF into multiple parts to segregate fields that should not be changed but this may cause a significant inconvenience to the operations of user B.

    Setting a field to read-only would allow full sharing of tasks while also maintaining data integrity.

    As it stands now, any member of the group can change any data and no one will know.

    Joel.

  4. islandmon wrote:

    <>

    Interesting, thanks for this.

    I have ended up redrawing objects instead of modifying existing ones just to keep working but the time it all takes + that of having to document and support the bug reports, it's just not fair.

    For any software in double-digit release numbers, issues such as this should not exist.

  5. I am getting a corrupted objects alert when saving drawings originally created in 10.5

    Essentially the file cannot be saved and my work is lost since the last save. I'm now saving every time after editing a couple of objects as this is happening pretty frequently (5-10 times a day).

    So far this only happens with polylines and polygons.

    Objects created in 11.5 are fine.

    Also suffering with sudden slow-downs which only closing, quitting and reopening will clear.

    This is really hurting my productivity and my confidence.

    Joel.

    Mac OS 9.2.2

  6. There seems to be a bug in behaviour of the smoothing functions with VW11.0.1/11.5

    More often than not, VW11 is grossly oversimplifying polygons so that they no longer bear any resemblance to the shape of the original object. Polygons of 100 vertices are reduced to something like 7 after any smoothing (or no smoothing).

    I cannot see why this happens with some polys and not others or why so many vertices are lost.

    Strangely, I have found that on most occasions when this happens, undoing, zooming in and retrying will allow smoothing to complete properly. However there are some polygons that will not smooth whatever I do and an example file is available here:

    With VW10.5 smoothing was consistently good.

    Joel.

    My system: PowerBook G3 series (WallStreet) 0.5GHz, 0.5GB

    System 9.2.2, CarbonLib 1.6

    VW11.5, 160MB partition.

  7. Jim,

    As far as I can tell, there is no access to the invokation of help via the F1 key in the Workspace editor. The Help menu is not among the Workspace menus.

    I have no assignments made in the Keyboard control panel for any of the F-keys and that system is disabled anyway.

    My assignments are all made via KeyQuencer.

    I had confirmation from a UK VW distributor that this is reproducable on their Mac OS 9 system but they had no idea how to disable it.

    According to the documentation, F1 is for Windows and Cmd-? is for the Mac (as one would expect) so has the Windows code accidentally made its way into this Mac release?

    Have you managed to supress it on your system or is it not happening under Mac OS X?

    Joel.

  8. > Maybe you could wrap the object inside a PIO

    > then use buttons in the info palette.

    I toyed with that but it's still a level of indirection that takes the immediacy from the interaction.

    There might be a good case for a 'control' layer in VW documents that sits above all others, onto which script enabled objects could be placed for the user to manage many drawing-contextual tasks like navigation.

    Thanks for your post.

    Joel.

  9. Yes, thank you.

    I'm sorry, but our standards should be higher than comparisons with the worst.

    There are countless good things in VW, things that let us do our jobs in a way that might not otherwise be possible, that's why we are here.

    But presented with something which breaks nearly every tenet of a graphical UI and is clearly defective, you have to say that it's below the standard we, and NNA, should aspire to.

    Text handling up to VW10.5 is in need of serious attention - nobody should be having to make excuses.

    Joel.

  10. JHE,

    Thanks for your reply.

    I'm not expecting WP, just competent text editing. I cannot think of a another Mac graphics application I have used in the last 20 years that has not had the capacity for WYSIWYG text. MacDraw circa 1986 did a better basic job of it - I just had a look.

    The text is not magnified for easier editing - this is a bug. When not being edited, the text is scaled, spaced and kerned incorrectly, when editing, it appears as it should other than not respecting its bounding box and losing all colour attributes - this is a fault.

    While it is certainly possible to build text externally, pasting will preserve the font and styles but not the colours - this mechanism is faulty.

    In 2004, can WYSIWYG text still be a problem to implement?

    Joel.

  11. I have previously only used small amounts of text for annotation (just a few words) but I now have a need for more presentational documents with larger amounts of styled text.

    The behaviour of these text objects is, frankly, bizarre. In fact I'm not sure I believe my eyes.

    1/. Clicking a text box to edit it causes the text to reflow as it expands slightly compared to the unselected state. This means it's impossible to have the text as you want it without many iterations. It also means that if you click on a box with the text tool where you wish to begin editing, the cursor actually appears elsewhere in the text and you have to find your place again.

    This redrawing of the text also causes the top lines to be hidden beyond the top of the box boundary requiring the cursor to be scrolled into them so they be brought back into view.

    What is causing the text boxes to expand and contract, reflowing the text each time?

    2/. In Mac OS, if the text is coloured, when editing it, all the text is rendered black making it virtually impossible to edit these attributes. The text box fill colour is also changed to white when editing.

    On Windows, these behaviours do not seem to happen.

    3/. There is no auto-scrolling as you type and the typed text or the cursor just disappear off the bottom of the window.

    4/. Window scrolling performance when editing a text box is extremely slow, slower than a window full of hundreds of objects.

    5/. Pasting text previously coloured in another application appears correctly following the paste but is rendered all black when exiting the box and then remains black thereafter.

    Editing text like this is a Kafkaesque nightmare - tell me I'm hallucinating.

    Is it any better under VW11?

    VW 10.5, Mac OS 9.2.2

    Zoom 100%, Layer Scale 1:1

    Adjust flipped text, No fill behind text - enabled

    Rotated Text display: Highest quality

  12. Why does this not work?

    LN := GetLName(ActLayer);

    Hide( ( (L= LN) & NOT (R IN ['Tree Record']) ));

    It should be possible to substitute any string in the search criteria with the value returned by a variable.

    This does not seem to apply for search criteria unless there is a special syntax for making programmatic searches.

    Thanks in advance.

    Joel.

    ----

    I believe I found the problem myself.

    The statement won't compile if the variable name is short - I used 15 character names for the variables used in search criteria and it works as expected.

    Interestingly, reducing the name back down to two characters after a longer one has been entered and run is not a problem.

    I have not yet determined what is the minimum length of variable name that can be used but 15 always works. Bug here somewhere.

    Joel.

    [ 06-13-2002: Message edited by: JoelS ]

×
×
  • Create New...