Home > Community > Forums > PCB SKILL > Problem with scripts that require file browsers

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

 Problem with scripts that require file browsers 

Last post Mon, Jun 30 2014 11:33 AM by Helen. 11 replies.
Started by mikebystedt 19 Jun 2014 02:22 PM. Topic has 11 replies and 1332 views
Page 1 of 1 (12 items)
Sort Posts:
  • Thu, Jun 19 2014 2:22 PM

    Problem with scripts that require file browsers Reply

    Does anyone know of a workaround that would allow a script or axlShell() commands to select and populate a
    file browser if it pops up?  It seems that the file browser form isn't recgonized.  So therefore no data can be entered.

    Specifically, after doing a File->Import and running, a summary report pops up with the details.  When I select "Save",
    a browser window pops up, but during Replay, the window is never selected, the filename never entered, and I can't
    save the file.

    I'm sure that someone else has encountered this at some point.  Any suggestions?

    Is there some sort of default FORM name that I could refer to that isn't being output to the script file during a Record session?

    Thanks, -Mike 

    • Post Points: 35
  • Fri, Jun 20 2014 1:46 AM

    • oldmouldy
    • Top 10 Contributor
    • Joined on Tue, Jul 15 2008
    • Woking, Surrey
    • Posts 1,445
    • Points 24,590
    Re: Problem with scripts that require file browsers Reply

    Try commenting out the "fillin" in the script, add a "#" to the beginning of the line. Without a fillin value provided, the "Save As" will wait for input. (At least it did for my test!)

    • Post Points: 20
  • Fri, Jun 20 2014 12:10 PM

    Re: Problem with scripts that require file browsers Reply

    Thanks,

    I'm not quite understanding how this would help during a -nographic script run though.
    It's not interactive at all.

    The issue seems to be that I need to be able to "setwindow" to the browser window, and know
    what the FORM name is.  Using the record and replay functionality, there isn't anything there.
    I'm seeing a generic "setwindow text" which doesn't work at all.

    Still looking for hints.  Below script doesn't work. It just leaves the File Browser empty and hanging.
    This is a literal Record session.

    Any other suggestions are GREATLY APPRECIATED!

    Thanks All, -Mike 



    -----------------------------------------------------------------------------------------

    setwindow pcb

    trapsize 1876380

    generaledit

    netin 

    setwindow form.niparams

    FORM niparams import  

    setwindow pcb

    setwindow text

    save

    fillin "MIKEtest.txt"

    setwindow text

    close

    setwindow form.niparams

    FORM niparams cancel  

    setwindow pcb

    generaledit  

    -------------------------------------------------------------------------------------------------------- 

    • Post Points: 20
  • Sat, Jun 21 2014 4:04 AM

    • oldmouldy
    • Top 10 Contributor
    • Joined on Tue, Jul 15 2008
    • Woking, Surrey
    • Posts 1,445
    • Points 24,590
    Re: Problem with scripts that require file browsers Reply

    OK, "nograph(ic)" is not interactive at all. IF I run script in interactive mode, having no "fillin" value for the "save" / "save as" waits for a value for the filename to save, with a "fillin" the file gets saved as that name and the script completes - "replay <script_file>" at the command window. Maybe this was changed at some point, which exact version are you running?

    • Post Points: 20
  • Tue, Jun 24 2014 9:45 AM

    Re: Problem with scripts that require file browsers Reply

    I'm running Allegro 16.6 for windows.

    If you've got a script you could post or send that handles those browser windows properly,
    I would really appreciate it.

    Thanks oldmouldy.

     -Mike 

    • Post Points: 20
  • Tue, Jun 24 2014 11:52 AM

    • oldmouldy
    • Top 10 Contributor
    • Joined on Tue, Jul 15 2008
    • Woking, Surrey
    • Posts 1,445
    • Points 24,590
    Re: Problem with scripts that require file browsers Reply

    First off, you will only be able to use the "save", or "saveas" in interactive mode. When you use "something like" "save" or "saveas" the "fillin" step puts the value in the browser window and closes it, so it will then "always" save(as) to the same filename. If you don't have a "fillin value" step the "save" / "saveas" will wait for user input for thje filename. If you want to have a script that changes the "fillin value" based upon "some other variable when it runs", you will need to take a look at the SKILL forum, there was recently a post from eDave where he had a SKILL script that wrote an Allegro script and then replayed that from the SKILL script. I would post the link but this post would be moderated as a result.

    • Post Points: 20
  • Thu, Jun 26 2014 11:12 AM

    Re: Problem with scripts that require file browsers Reply

    Thanks oldmouldy,

    But the problem I believe I'm looking at, is not so much that the "fillin value" needs to be dynamically tweaked,
    but that I can't actually get a handle to the browser window.  

    I'm actually attempting to record a script, then issuing the specific statements I want through
    axlShell() commands directly in a SKILL file.  I can't do a fillin whatsoever if I can't set the browser window to get
    ready to accept a value of any sort at all.  The method of sending out the commands, whether via a replay script
    or axlShell() calls, is just a programming decision.  However, neither method will work if I can't get a window handle
    for the "set window" command. Recording the script and reviewing, shows the "fillin" lines, but no window handle to set
    so that it can get the data loaded in correctly.

    So even the simplest of records and replays doesn't work if accessing the file browser is part of the equation.

    Is there some sort of standard handle for this sucker?  So that I can make the file browser the active window, and then
    do whatever I need to?  It's almost like the file browser window is completely invisible, although the commands thrown
    at it are still being recorded.

    Thanks,

    -Mike 

     

    • Post Points: 20
  • Thu, Jun 26 2014 11:36 AM

    • oldmouldy
    • Top 10 Contributor
    • Joined on Tue, Jul 15 2008
    • Woking, Surrey
    • Posts 1,445
    • Points 24,590
    Re: Problem with scripts that require file browsers Reply

    You can't get a handle on the browser window because all it does is provide the "fillin" value. For example, if the "save" / "save as" command in the script is followed by a "fillin" command, the browser window won't appear because save / save as already has the answer needed in the "fillin value" for the script to proceed, if it is not followed by a "fillin" command, the script waits for the user to provide the "fillin" value through the file browser window. So, what you need to manipulate is the "fillin value", unless you want no "fillin" command and the user prompted for input through the file browser window. You cannot manipulate the file browser window but you can manipulate the answer that would have come from it with the "fillin value"

    • Post Points: 5
  • Thu, Jun 26 2014 11:47 AM

    • fxffxf
    • Top 25 Contributor
    • Joined on Thu, Jul 17 2008
    • ., AK
    • Posts 298
    • Points 4,735
    Re: Problem with scripts that require file browsers Reply

    If writing a Skill program you look at axlDMFileBrowse which will invoke a file browser and give you control over most of the features available with the browser. For allowing a user to select a directory you can use axlDMDirectoryBrowse.

    • Post Points: 20
  • Thu, Jun 26 2014 1:38 PM

    Re: Problem with scripts that require file browsers Reply

    Thank you Gents for the feedback.

    I've used the file browsers in my SKILL code.

    My main problem though, is that I've been trying to save the report that is generated after doing a "File->Import".
    The report pops right up and is shown in an .htm based window, but when I hit "Save" I can't do anything with it.

    I simply want to save the data somehow.  

    I'm not seeing an option to actually capture it

    Is there a standard location where the "temp" files are kept with a standard naming convention?
    I'm assuming that there is a generated report that is being referenced and loaded into the htm file viewer.
    If I can locate that, I could simply copy the file.  That would work as well.

    Thanks,

     -MIke  

    • Post Points: 35
  • Fri, Jun 27 2014 4:45 AM

    • fxffxf
    • Top 25 Contributor
    • Joined on Thu, Jul 17 2008
    • ., AK
    • Posts 298
    • Points 4,735
    Re: Problem with scripts that require file browsers Reply

    Normally these are logfiles created during the import/export operation. Except for Cadence import logic which creates a netrev.lst, the files have a .log extension. The easies way to determine the name is to open a Windows File Explorer in the directory with the board,enable list file and sort by Modified date with the most recent date at the top of the window. Run the Allegro Import/export operation. The .log (or netrev.lst) file that appears at top of the Windows Explorer is the file you want.

    • Post Points: 5
  • Mon, Jun 30 2014 11:33 AM

    • Helen
    • Top 500 Contributor
    • Joined on Wed, Jul 23 2008
    • Posts 17
    • Points 165
    Re: Problem with scripts that require file browsers Reply

     Add  "viewlog -last" and you code will save "MIKEtest.txt". By default this report saved to ./Logs/netrev.lst

    =========== 

    netin

    setwindow form.niparams

    FORM niparams import 

    setwindow pcb
    viewlog -last     ### <========
    setwindow text

    save

    fillin "MIKEtest.txt"

    setwindow text

    close

    setwindow form.niparams

    FORM niparams cancel 

    setwindow pcb

    generaledit 

    • Post Points: 5
Page 1 of 1 (12 items)
Sort Posts:
Started by mikebystedt at 19 Jun 2014 02:22 PM. Topic has 11 replies.