Jump to content

ccroft

Member
  • Posts

    522
  • Joined

  • Last visited

Reputation

3 Neutral

1 Follower

Personal Information

  • Occupation
    cabinetmaker
  • Hobbies
    photograpy
  • Location
    western canada

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'm still back on 2009 and I think it's mainly for that reason. I'll have to update all my dialogs to Modern Dialog if I ever want to update vWorks. Anyway, I think you'll want GetItemText and SetItemText. Sorry 'bout that.
  2. Have a look at SetField and GetField. CreateEditText is used to create the field and set the default text that shows in the dialog box... if you want to.
  3. Option Shift 8, Option J, Option K Open Keyboard viewer and you can see a bunch of these things.
  4. Hi Jeff, I actually haven't written anything meaningful in quite some time, and I'd like to thank you for posting and tweaking my interest again, and trying to see what you were up to. If I may I'd make a couple more comments. I think you'll find that you're doing a few things in your code that don't need to be done. You don't need to have a separate "fill the first location" line. My example handles that in the first line of the loop. IE the first time we look at the array we can assume that it's blank. Actually, some might say that we need some error checking to make sure, but I've never done that and in some 8 years of using a tool daily that doesn't check I haven't had a failure. Also, the section at your comment {IF NAMES DONT MATCH ADD 1 to arraycnt to look at next element} isn't needed if you increment the index after the logic is finished evaluating things. If neither condition is met, then the index increments to look at the next location in the array. So let's say we're on the fifth instrument and it hasn't yet been entered into the array. The logic looks at each value in the array consecutively and doesn't find a match. It then encounters a blank location. That means that we've looked at every instrument in the array, so we add the value there. You can use the way an array is filled to your advantage. The fact that I'm using 'done' to control the loop is essentially the same as what you're doing with: arrayCnt := kmaxArray; I've just rearranged things a bit. On the subject of error checking: you may want to add a safety valve in case something funky starts happening. Something like: While (not done) | (index < arrayCnt) Do.... If arrayCnt = kMaxArray then done := true; AlertMessage('funkiness encountered)'; I have something like that in a script, but it's never gotten funky. :-(
  5. Here's how I've looked at values and added to array, or counted them if they were already in the array. It's the same approach if the values are in another array, or the values are derived from a PIO. In my EG I already have two procedures: sameValue and newValue. You already know what each does. You could write out the procedures directly in the loop if it made more sense to you. In any case, the last thing that happens in each is that a boolean becomes true. If conditions are met and either procedure runs then 'done' becomes true, we exit the loop and move on to the next value to either be counted or added to the array. If neither condition is met then done stays false and we move to the next location in the array until one of the procedures runs, and then we're done with that value. pioName:= aValueFromArrayOrObject done := false; index:= 1 While (not done) Do Begin If array[index] = 0 then newValue else IF array[index] = pioName then sameValue; index := index+1; End; This could be a procedure in a ForEach statement. ForEach looks at every object in the drawing that matches your criteria, gets it's name and then runs above to either load the array or increment the counter in the array accordingly. With this approach you build one properly summarized array from the get go. This *might* be a more efficient way, but if what you've got is working for you well... why rock the boat?
  6. Are you doing something else with xArray besides summarizing it with another array? IE does xArray exist only to be summarized? If so, I'd do the counting while loading xArray. The loading procedure looks at an object. If it's not been seen before it adds it to the array. If the name is on the array it increments the count and moves on to next object. You'd need a two dimensional array. Column one is intelCount and two is intelData. Of course, you may have needs that disqualify this approach, but if not it seems a lot simpler to me. The entire loading and counting is done within one loop, there's one less array to manage, and one less array to traverse. My apologies if I'm stating the obvious.
  7. Even better! I didn't think of doing it all with criteria.
  8. I'd try one of the ForEach calls with something very similar to the example in function reference under GetRField that said "IF GetRField = FieldValueMeLookFor THEN HandleToObjectMeLookFor := H". If you used ForEachObject you could restrict the number of objects queried with some sort of Criteria filter. Possibly by PIO name, since if you know the value you're looking for you probably also know the name of the object it's attached to. The 'record' parameter in GetRField(h,record,field) is the PIO's name, and field name is... well usually it's the name of the field you see in OIP. I haven't been around much lately so there's a pretty good chance I've forgotten something, but there's plenty of other posters who'll know this routine. Hopefully they're enjoying a lovely Labour Day weekend. Just thought I'd give you something to start with until one of them comes along.
  9. If the above is true then it must have something to do with the different behaviours of VSM and VSO. In past posts you were working with nested pio's.... parent PIO placing other PIO's. Is this code part of that project? All of my run-ins with out of memory problems have involved loops running out of control. With nested VSO's it is possible to construct event loops, where the parent changes the child, and the child changing causes the parent to change, and on and on until all memory is eaten up. Above is total guesswork and conjecture, but what I'm trying to suggest is that instead of thinking along the lines of forcing more memory or tweaking bits of code, the problem may be more in the implementation of the code: the differences between VSM and VSO. The principal difference as I understand it is the constant event monitoring of VSO. On the other hand, if Josh's *very* generous offering solves the problem...
  10. If you select a worksheet-on-drawing, and convert it to group it becomes a dumb graphic/text object...frozen in time. You could copy/paste that into another file, or reference the layer it's on into another file. Note that the dumb schedule will not update to reflect changes in the target file, and the worksheet no longer shows as 'Worksheet on Drawing' in resource browser in target file. So if you make changes to target file, you will have to delete the dumb worksheet, go back into resource browser and select 'Worksheet on Drawing' and convert the worksheet-on-drawing to group all over again. If you have referenced the worksheet into 'Schedules File' those changes will be updated. So it's hardly automatic and introduces lots of opportunity for error when managing changes, but it does work in VW '09. There might be a better way.
  11. We don't own CNC, but I output dxf/dwg for stone counter-tops and also for some of the more complicated millwork parts when it makes sense. Haven't had any trouble at all. Mostly curved stuff but only since upgrading to 2009. Sorry to hear about Tom's trouble. So far it's been very accurate for us. Of course, we're a millwork shop so it's not like we're building space shuttles or anything, but I've scrutinized the work very closely in case we need something really critical in the future.
  12. Been using this mouse for about 2 weeks. I didn't instal any 3rd party software. Pan and zoom work really well for me, so something funny's going on here. Maybe you should dump the MagicPrefs app and try again. Or delve more deeply into how that app works.
  13. I think you'll have to do it 'manually'. I've never needed to do exactly this, but I would try stepping thru the array with a while loop with something along these lines: index:=1; stringMatch;=False; While NOT stringMatch Do ????IF array[index] = theString THEN StringMatch := TRUE ????ELSE index:= index+1; Message(index); {if you'd like to check} The loop will terminate when it finds a match, and index should be what you're looking for. (or it might be index-1...) If there isn't a match you'll have some trouble, so you better have a limiter in there like: While (index < arrayLimit) & (NOT stringMatch) DO ??etc. Since your using dynArray you've already calculated the array size, so you could probably just use that variable in place of arrayLimit.
  14. No Ray....YOU da' man. But you need to re-read my post. I never for a minute thought you would suggest an array. From our history I figured you'd know that would be my solution, since it seems to be my go to move when there's any kind of handle trouble. I like your 'look-ahead'. Haven't seen the Geek here for a while. Good to seeya!
  15. Seems like that should work. You must be getting kicked out of the loop due to a nil handle. Could it be that once the PIO is moved out of the wall NextObj can't figure out what's next in the list? I think Ray knows what I'm about to suggest... Build a quickie array of all objects in wall = 86, and step thru that. (or maybe something else is happening that I can't see)
×
×
  • Create New...