opensta-devel Mailing List for OpenSTA (Page 13)
Brought to you by:
dansut
Menu
▾
▴
opensta-devel — OpenSTA developer discussions
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(1) |
Nov
(3) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
(19) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(12) |
Dec
(5) |
| 2002 |
Jan
(17) |
Feb
(11) |
Mar
(11) |
Apr
(16) |
May
(11) |
Jun
(9) |
Jul
(22) |
Aug
(8) |
Sep
(22) |
Oct
(9) |
Nov
(11) |
Dec
(5) |
| 2003 |
Jan
(15) |
Feb
(26) |
Mar
(35) |
Apr
(85) |
May
(103) |
Jun
(35) |
Jul
(37) |
Aug
(19) |
Sep
(16) |
Oct
(11) |
Nov
(4) |
Dec
(10) |
| 2004 |
Jan
(11) |
Feb
(24) |
Mar
(7) |
Apr
(1) |
May
(13) |
Jun
(6) |
Jul
(7) |
Aug
(93) |
Sep
(4) |
Oct
(30) |
Nov
(16) |
Dec
(64) |
| 2005 |
Jan
(30) |
Feb
(4) |
Mar
(8) |
Apr
(22) |
May
(63) |
Jun
(32) |
Jul
(11) |
Aug
(14) |
Sep
(1) |
Oct
(11) |
Nov
(2) |
Dec
(13) |
| 2006 |
Jan
(53) |
Feb
(6) |
Mar
(6) |
Apr
(6) |
May
(7) |
Jun
(8) |
Jul
(7) |
Aug
(3) |
Sep
(2) |
Oct
(6) |
Nov
(3) |
Dec
(11) |
| 2007 |
Jan
(2) |
Feb
(9) |
Mar
|
Apr
(10) |
May
(5) |
Jun
(1) |
Jul
(14) |
Aug
(5) |
Sep
|
Oct
(10) |
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(3) |
Sep
(1) |
Oct
|
Nov
|
Dec
(2) |
| 2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2005-05-12 22:23:49
|
Bugs item #703813, was opened at 2003-03-14 15:09 Message generated for change (Settings changed) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=703813&group_id=10857 Category: GUI Issue Group: Inconvenience >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Danny Faught (faught) Assigned to: Daniel Sutcliffe (dansut) Summary: internal error for long input on numeric properties Initial Comment: 1. Open or create a test and view it in the test pane in Commander. 2. Click the VUs tab. 3. Enter 32 digits in the "Total number of virtual users property", e.g. - "99999999999999999999999999999999" After typing the last character (and before pressing Enter) , I get an error dialog that says "TestPlugin ! Please enter an integer." This looks like an internal error. I did enter an integer, it's just larger than what the application wants. The field should just stop accepting input when it's full. This applies to most properties that accept numeric values. ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2004-12-12 18:39 Message: Logged In: YES user_id=19748 A fix for this and a number of issues with the integer fields in this area of Test configuration has been merged into the CVS head. This will become generally available in the OpenSTA 1.4.3 release. Thanks to Thierry @ Kereval for providing this fix. ConfigurationTabDLL.dll: 1.4.3.3 OpenSTA: 1.4.3.9 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=703813&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-12 22:12:15
|
Bugs item #703399, was opened at 2003-03-13 23:10 Message generated for change (Settings changed) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=703399&group_id=10857 Category: GUI Issue Group: Inconvenience >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Danny Faught (faught) Assigned to: Daniel Sutcliffe (dansut) Summary: incorrect highlighting for first row in test pane Initial Comment: 1. Open a test in the test pane in Commander (use one that has at least two task groups to illustrate the issue more clearly). 2. Click on a column header in the test pane, such as the button that says "start". 3. Click on the data item in that column in the first row. Though the properties for that item show up in the Properties pane, the entire column is still highlighted. There's no visual cue showing which item is represented in the Properties pane. 4. Click the data item in the second row in the same column. 5. Click on the data in the first row again. Often, but not always, the item in the second row is still highlighted even though the item in the first row has focus. This only seems to happen when selecting data in the first row. The column highlight disappears when selecting an item in lower rows. I'm using OpenSTA 1.4.1 on Windows 2000. ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2004-12-12 17:43 Message: Logged In: YES user_id=19748 This first row element selecting/highlighting issue actually showed itself in most of the grid/tables used throughout the OpenSTA toolset. A fix for this problem has been merged into the CVS head. This will become generally available with the OpenSTA 1.4.3 release. Thanks to Thierry @ Kereval for providing this fix. ConfigurationTabDLL.dll: 1.4.3.2 MonitoringTabDLL.dll: 1.4.3.2 XAuditViewer.ocx:1.4.3.2 NTPerfPlugin.exe: 1.4.3.3 SNMPPlugin.exe: 1.4.3.2 RelayCfg.exe: 1.4.3.2 OSCommander.exe: 1.4.3.2 TModeller_web.exe: 1.4.3.4 OpenSTA: 1.4.3.8 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=703399&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-12 22:11:05
|
Bugs item #695108, was opened at 2003-02-28 10:21 Message generated for change (Settings changed) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=695108&group_id=10857 Category: Command Line Group: Inconvenience >Status: Closed Resolution: Fixed Priority: 3 Submitted By: Daniel Sutcliffe (dansut) Assigned to: Daniel Sutcliffe (dansut) Summary: TestInit does not have default sample_rate Initial Comment: The TestInit --start command line requires that both -T test_name and -S smaple_rate be specified. It would make life easier if the sample rate could default to some value if not specified. Also: -S sample_rate is not documented at all. ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2005-01-03 16:20 Message: Logged In: YES user_id=19748 The above fix has been merged into the CVS HEAD. It will become generally available in the OpenSTA 1.4.3 release. Including in this fix are an additional -wait command line parameter. This causes TestInit not to exit until the test was finished, this code was submitted by Dan Williamson. Also improvements have been made to avoid the possibility of TestInit looping forever - the impetus for this came from comments made by Jerome Delemarche about TestInit looping forever id an invalid test name is given... turns out that this is not the problem though and TestInit does return it is actually the TestManager that loops forever - a bug will be filed for this issue. This little utility really needs completely rewriting as there are obvious possiblities of may problems because of the "loose" way it communicates with the architecture... for 1.5 TestInit.exe 1.4.3.2 OpenSTA 1.4.3.16 ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2004-12-22 16:16 Message: Logged In: YES user_id=19748 I've fixed this so the default sample_rate when no -S is specified is set to 0(zero). This means that tests started from a TestInit in this manner won't be able to be monitored from the Commander, but this is more efficient and seemed to be how members of the users list reported that they were using TestInit anyway... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=695108&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-12 22:10:24
|
Bugs item #637865, was opened at 2002-11-13 12:07 Message generated for change (Settings changed) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=637865&group_id=10857 Category: HTTP Capture Group: Inconvenience >Status: Closed Resolution: Fixed Priority: 6 Submitted By: Celso Hernando (atisadm) Assigned to: Daniel Sutcliffe (dansut) Summary: Invalid script generation/capture for binary POSTs Initial Comment: We´re trying to capture the dialog between a java applet and the Web Application Server. After the login process ( everything is OK) the applet sends a POST which contains a binary buffer as the BODY of the request. The capture then shows: ....... ,BODY "binary(636)" ....... When I run the script, I´m sending 636 A´s to the WAS, but the application on the other side expects a meaningfull buffer to progress with the transaction I´m trying to test. ¿Would it be possible to capture this binary buffer in order to send it "as is" in the future executions ? ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2004-12-12 15:34 Message: Logged In: YES user_id=19748 The mentioned fix has been merged into the CVS head. It will become generally available in the OpenSTA 1.4.3 release. gwhttp.dll: 1.4.3.3 OPenSTA: 1.4.3.6 ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2004-12-12 12:50 Message: Logged In: YES user_id=19748 I have a fix for this issue which also partially corrects another bug and doesn't produce a entirely valid SCL. Details of this and the full fix are below: Code for binary bodies will never be generated from a recording. Recording of multipart/form-data file uploads that were "binary" used to generate special POST BODY code. If the body was less than 255 bytes the body would be shown as "0xXXYYZZ..." and above this as "binary(NNN)". The logic to spot what was "binary" wasn't very good and the binary(NNN) notation was next to useless. The fix causes all BODY data to be represented as strings correctly encoded with SCL mnemonics as required. Replay of the old code formats has not changed. On it's own this fix can generate invalid SCL (lines and strings that are too long), this fix also corrects some of the issues with B#1049672. The full fix for B#1049672 should ensure correct SCL is generated. ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2004-10-25 13:36 Message: Logged In: YES user_id=19748 This behaviour is confirmed and accepted. Any multipart/form-data POST body which is over 255 bytes and seen as "binary" is represented in this manner. The playback of a buffer of A's does not match expected multipart/form-data body in any way and so doesn't make sense. Further more the decision of whether a buffer is "binary" or not is flawed. Any character which is non-printing and not a <CR> or <LF> will cause the binary designation - this includes the tab character. This problem is related to the issues of recording purely text uploads (bug 1049672): http://sourceforge.net/tracker/index.php?func=detail&aid=1049672&group_id=10857&atid=110857 and will probably fixed in the same update. ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2003-05-01 13:42 Message: Logged In: YES user_id=19748 This may be related to the incorrectly generated multipart form scripts. Further checking requireed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=637865&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-12 22:09:43
|
Bugs item #475128, was opened at 2001-10-25 20:04 Message generated for change (Settings changed) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=475128&group_id=10857 Category: HTTP Capture Group: Crash >Status: Closed Resolution: Fixed Priority: 6 Submitted By: Chun Wong (cw202) Assigned to: Daniel Sutcliffe (dansut) Summary: Binary multipart form uploads can crash the gateway Initial Comment: Support the capturing or scripting of Multipart forms. Need to incorporate upload functionality. ---------------------------------------------------------------------- Comment By: gauravsach (gauravsach) Date: 2005-02-18 08:57 Message: Logged In: YES user_id=1222378 Getting 404 error while downloading a image in Open STA during recording.I cannot skip the step as it is mandatory in the application.Please suggest. ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2004-10-25 13:41 Message: Logged In: YES user_id=19748 Found problem in recording multipart/form-data POSTs that contain NULL characters. End of buffer pointer was lost and corruption occurred which may lead to crash. Code updated to be more careful about where the end of HTTP body was. Work on diagnosing and fixing this issue was kindly sponsored by Marco @ VoxSurf. Thanks. gwhttp.dll: 1.4.3.2 OpenSTA: 1.4.3.5 ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2004-10-18 19:38 Message: Logged In: YES user_id=19748 I'm changing the Summary of this bug report to represent the fact that this issue is specifically the problem where the gateway fails to record binary uploads with "unknown exception". So is not the "^J" issue covered on the majority of: http://portal.opensta.org/faq.php?topic=BugsMultipartForm that will get it's own new bug and the page will be updated. Contrary to what I have said there "may" be further issues to do with replaying binary data containing NULL characters... again this needs it's own bug when it has been clarified. ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2004-10-14 09:47 Message: Logged In: YES user_id=19748 I'm possibly taking this on for a customer so any useful information you can pass on to me would be appreciated. ---------------------------------------------------------------------- Comment By: Philip Vaartstra (philipv) Date: 2004-05-20 13:40 Message: Logged In: YES user_id=787237 I have found (using OpenSTA 4.2) that attempting to record an upload will crash the recording session. This is unfortunate. Worse is that it does not restore all the browser preferences including home page, and proxy server. It leaves the proxy server set to port 81 on the local machine. Furthermore, it seems to corrupt the application (or maybe just its own proxy server) to the point where it requires a re- install. ---------------------------------------------------------------------- Comment By: Antony Marcano (antonym) Date: 2003-06-02 04:30 Message: Logged In: YES user_id=403001 Note to developer - contact an...@et... for detailed explaination of suspected cause of this error. ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2003-04-25 08:28 Message: Logged In: YES user_id=19748 Playback of multipart forms does actually work. Recording multipart forms however produces invalid scripts, this is a Bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=475128&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-12 22:05:34
|
Bugs item #414448, was opened at 2001-04-06 19:29 Message generated for change (Settings changed) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=414448&group_id=10857 Category: GUI Issue Group: Inconvenience >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Philip K Chung (pondor) Assigned to: Daniel Sutcliffe (dansut) Summary: DOM parser confused by 'extra' HTML Initial Comment: the DOM parser seems to crap out if there are any more HTML elements after "</HTML>". attached is a zip file containing two simple forms. both are similar except "simple_form_extra.htm" has some extra stuff after the "</HTML>" end-tag. simple_form_extra.htm is the one that makes the DOM parser fail. ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2004-05-18 14:27 Message: Logged In: YES user_id=19748 This problem has been checked to be the same as 760485 using the provided HTML. The fix has been merged into the CVS HEAD. It will become generally available in release 1.4.3. The fix creates a new top level folder to the HTML tree, called 'document' and places any 'rooted' HTML tags below this. Previously only the last 'rooted' HTML tag would show up in the HTML tree tab. Work on diagnosing and fixing this issue was kindly sponsored by Bernie @ Performax, Thanks. Modeler: 1.4.3.2 OpenSTA: 1.4.3.3 ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2003-08-05 15:19 Message: Logged In: YES user_id=19748 I'm going to guess that this problem may in fact be related to 760485 and take it under my wing to try out the fix for this with the zip files. 760485 has nothing to do with replay but it maybe this problem was incorrectly classified. If the original reporter is still around and could confirm or deny this, then that would be great. ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2003-05-01 14:27 Message: Logged In: YES user_id=19748 Is this in replay or in the Modeler? I cannot see how this would happen under capture but anything is possible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=414448&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-10 23:04:34
|
Bugs item #1199466, was opened at 2005-05-10 19:02 Message generated for change (Settings changed) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199466&group_id=10857 Category: Architecture Group: Behavioral Status: Open >Resolution: Accepted Priority: 5 Submitted By: Daniel Sutcliffe (dansut) >Assigned to: Daniel Sutcliffe (dansut) Summary: Old FVR/TOF files appear to be cached at Test run time Initial Comment: When you run a Test the compiled scripts (.TOF) and the .FVR files they reference are copied into the %OPENSTA_HOME%\Engines\Temp\ dir of the machine they are to be executed on. These are the copies that are used during actual test running - so editing the .FVRs in the Repository won't do anything during a test run, no suprise. What appears to be the problem here is that the .FVR files can get "stuck" so the first copy that gets placed in the Engines\Temp\ cannot be overwritten or deleted. So the next time you run a Test this will be used again. Because this file cannot be deleted even with the Commander closed it's probably something in the Architecture that is holding the file exclusively open - the fact that it can start working again suggests to me that whatever it is eventually times out or sometimes works. It is not unimaginable that the same thing could happen with the .TOF files giving the old cached Scripts that has also been reported. Couldn't reproduce this though... Workaraound: - Close down nameserver and delete all .TOF and .FVR files from %OPENSTA_HOME%\Engines\Temp\ - restart nameserver. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199466&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-10 23:02:04
|
Bugs item #1199466, was opened at 2005-05-10 19:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199466&group_id=10857 Category: Architecture Group: Behavioral Status: Open Resolution: None Priority: 5 Submitted By: Daniel Sutcliffe (dansut) Assigned to: Nobody/Anonymous (nobody) Summary: Old FVR/TOF files appear to be cached at Test run time Initial Comment: When you run a Test the compiled scripts (.TOF) and the .FVR files they reference are copied into the %OPENSTA_HOME%\Engines\Temp\ dir of the machine they are to be executed on. These are the copies that are used during actual test running - so editing the .FVRs in the Repository won't do anything during a test run, no suprise. What appears to be the problem here is that the .FVR files can get "stuck" so the first copy that gets placed in the Engines\Temp\ cannot be overwritten or deleted. So the next time you run a Test this will be used again. Because this file cannot be deleted even with the Commander closed it's probably something in the Architecture that is holding the file exclusively open - the fact that it can start working again suggests to me that whatever it is eventually times out or sometimes works. It is not unimaginable that the same thing could happen with the .TOF files giving the old cached Scripts that has also been reported. Couldn't reproduce this though... Workaraound: - Close down nameserver and delete all .TOF and .FVR files from %OPENSTA_HOME%\Engines\Temp\ - restart nameserver. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199466&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-10 22:52:43
|
Bugs item #1199460, was opened at 2005-05-10 18:52 Message generated for change (Settings changed) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199460&group_id=10857 Category: GUI Issue Group: Behavioral Status: Open >Resolution: Accepted Priority: 5 Submitted By: Daniel Sutcliffe (dansut) >Assigned to: Daniel Sutcliffe (dansut) Summary: Updating FVR from Modeler doesn't work Initial Comment: The symptom here is that when you intitally create an file variable file (FVR) it is editable and saves correctly, but thereafter it appears to revert to its original contents sometime after you try to update it. Here's what happens: When you open a script in the Commander for the Modeler to edit, a temp dir is created in Repository\.TMP\ called CYR???.tmp\ . Into this dir are copied; the scripts .ALL file from Repository\Captures, the actual SCL script (.HTP) from Repository\Scriptsand any referenced .FVR files from Repository\Data\ . While you are editing your script, if you compile and/or run it then this temp copy is updated. When you run the script from the Modeler it uses the files in this temp dir - except the .FVR files which are used from the Repository\Data\ directory. Any edits you perform to the .FVR using the GUI are also performed on the copies in Repository\Data\ . So if you edit an FVR then run your script you won't see an issue... Here's the crunch though - when you save your SCL script in the Modeler the files from the Repository\.TMP\CYR???.tmp\ are copied into their normal places in the Repository! And yes, this includes the .FVR files that have been saved from when you first opened the script... :-) I guess that GUI editing and running were supposed action on the Repository\.TMP\CYR???.tmp\ copies of the .FVRs. The fix could make this happen, or simply get rid of the .FVRs in this temp dir... I'd like to hear opinions on which of these is preferable from the user point of view? Workarounds: - edit .FVRs by hand with Modeler closed - delete .FVRs in Repository\.TMP\CYR???.tmp\ after starting Modeler ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199460&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-10 22:52:03
|
Bugs item #1199460, was opened at 2005-05-10 18:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199460&group_id=10857 Category: GUI Issue Group: Behavioral Status: Open Resolution: None Priority: 5 Submitted By: Daniel Sutcliffe (dansut) Assigned to: Nobody/Anonymous (nobody) Summary: Updating FVR from Modeler doesn't work Initial Comment: The symptom here is that when you intitally create an file variable file (FVR) it is editable and saves correctly, but thereafter it appears to revert to its original contents sometime after you try to update it. Here's what happens: When you open a script in the Commander for the Modeler to edit, a temp dir is created in Repository\.TMP\ called CYR???.tmp\ . Into this dir are copied; the scripts .ALL file from Repository\Captures, the actual SCL script (.HTP) from Repository\Scriptsand any referenced .FVR files from Repository\Data\ . While you are editing your script, if you compile and/or run it then this temp copy is updated. When you run the script from the Modeler it uses the files in this temp dir - except the .FVR files which are used from the Repository\Data\ directory. Any edits you perform to the .FVR using the GUI are also performed on the copies in Repository\Data\ . So if you edit an FVR then run your script you won't see an issue... Here's the crunch though - when you save your SCL script in the Modeler the files from the Repository\.TMP\CYR???.tmp\ are copied into their normal places in the Repository! And yes, this includes the .FVR files that have been saved from when you first opened the script... :-) I guess that GUI editing and running were supposed action on the Repository\.TMP\CYR???.tmp\ copies of the .FVRs. The fix could make this happen, or simply get rid of the .FVRs in this temp dir... I'd like to hear opinions on which of these is preferable from the user point of view? Workarounds: - edit .FVRs by hand with Modeler closed - delete .FVRs in Repository\.TMP\CYR???.tmp\ after starting Modeler ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199460&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-10 22:43:44
|
Bugs item #1199448, was opened at 2005-05-10 18:35 Message generated for change (Settings changed) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199448&group_id=10857 Category: GUI Issue Group: Behavioral Status: Open >Resolution: Accepted Priority: 5 Submitted By: Daniel Sutcliffe (dansut) Assigned to: Daniel Sutcliffe (dansut) Summary: Result Graphs scaled wrong if Windows DPI not default Initial Comment: If you've changed the default Windows DPI setting (96dpi) then the Result graphs will be generated scaled wrong to fit in the window. If the DPI value has been made larger then the graph may actually be bigger than the window and no scroll bars will be provided, meaning you won't be able to see the top right corner of the graph. Normally the scaling of the graph follows the window size so the graph always exactly fits in the Window. Workaround: change DPI setting back to 96dpi, or export data and generate graphs yourself in spreadsheet software. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199448&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-10 22:35:08
|
Bugs item #1199448, was opened at 2005-05-10 18:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199448&group_id=10857 Category: GUI Issue Group: Behavioral Status: Open Resolution: None Priority: 5 Submitted By: Daniel Sutcliffe (dansut) Assigned to: Daniel Sutcliffe (dansut) Summary: Result Graphs scaled wrong if Windows DPI not default Initial Comment: If you've changed the default Windows DPI setting (96dpi) then the Result graphs will be generated scaled wrong to fit in the window. If the DPI value has been made larger then the graph may actually be bigger than the window and no scroll bars will be provided, meaning you won't be able to see the top right corner of the graph. Normally the scaling of the graph follows the window size so the graph always exactly fits in the Window. Workaround: change DPI setting back to 96dpi, or export data and generate graphs yourself in spreadsheet software. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199448&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-10 21:36:35
|
Bugs item #768782, was opened at 2003-07-09 19:22 Message generated for change (Comment added) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=768782&group_id=10857 Category: SNMP Monitor Group: Behavioral >Status: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Eric Doherty (jedoh) Assigned to: Nobody/Anonymous (nobody) Summary: SNMP collector only displays "12" for Solaris8 box Initial Comment: OpenSTA v1.4.2, running on Win2K. Target machine: Sun 450 / Solaris 8. Attempting to monitor performance of Sun machine; specifically, trying to gather CPU stats. First, tried setting up a collector using the instructions in this article: http://portal.opensta.org/modules.php? op=modload&name=News&file=article&sid=26. No errors were indicated, but the monitor graph always reported a value of "12," even though I was expecting some exponential value (machine has been up for months). At this point, I wanted to do some further investigation. The Sun box did not have snmpwalk on it, and in response to my query, a Sun rep directed me to Net- SNMP. After installing Net-SNMP and playing around with it a bit, I found that the UCD-SNMP-MIB had available the system, user, and idle time percentage figures I really wanted (yes, I am aware that these values are somewhat nebulous, but they are "good enough" for my purposes). I was able to read the desired values via command line on the Solaris box (snmpget), AND with the Getif tool running on the same Win2K machine that OpenSTA is on, but when I try to configure a collector with the query value equal to the numeric reference returned by snmptranslate, OpenSTA still returns a value of "12." I also tried several variations of the query value, but with no luck. Could this perhaps be related to issue #693443? ---------------------------------------------------------------------- >Comment By: Daniel Sutcliffe (dansut) Date: 2005-05-10 17:36 Message: Logged In: YES user_id=19748 Issue merged with new bug# 1199408 ---------------------------------------------------------------------- Comment By: Damien Bonvillain (nkame) Date: 2004-01-20 08:37 Message: Logged In: YES user_id=237265 I had the same problem but totally not related with Solaris 8. After inspection of the SNMP dialog with a packet sniffer, it seems that OpenSTA don't send pure OID as is, and does some magig. In my case I tried to get 1.3.6.1.4.1.2725.1.3.2, but OpenSTA was requesting sysUpTime.6.1.4.1.2725.1.3.2, that is it assumed my OID was relative to the MIB-2 root (1.3.6.1.2.1). Changing my requested OID to a "MIB-able" name (enterprises.2725.1.3.2) solved the problem. I still have from time to time a 12 appearing, perhaps due to a time-out or another non-handled error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=768782&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-10 21:35:25
|
Bugs item #693443, was opened at 2003-02-26 01:07 Message generated for change (Comment added) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=693443&group_id=10857 Category: SNMP Monitor Group: Behavioral >Status: Deleted >Resolution: Duplicate Priority: 7 Submitted By: Ranjit Shewale (jcrvs) Assigned to: Daniel Sutcliffe (dansut) Summary: Opensta displays 1 value for SNMP collectors for Weblogic7.0 Initial Comment: While monitoring the weblogic server using SNMP collectors, opensta does not report the right data. It always displays the values as 1(one) for all parameters monitored. OS:- -Windows NT4.0 server with SP6 -Weblogic server 7.0 -opensta1.4.1 Weblogic and opensta are installed on the same.machine. Description:- 1. Enable the weblogic SNMP using the weblogic console and connecting to the weblogic server (by default it is off). 2. Re-start the weblogic server. 3. Use the command line to ping the weblogic server (e.g. F:\ucd-snmp\bin>snmpgetnext -c public localhost enterprises.bea.wls.executeQueueRuntimeTable.execute QueueRuntimeEntry.e xecuteQueueRuntimeExecuteThreadCurrentIdleCount output is : enterprises.bea.wls.executeQueueRuntimeTable.execute QueueRuntimeEntry.executeQueueRuntimeExecuteThre adCurrentIdleCount."8dda582af9a989133711b8a2cc5da8f d" = 13 and F:\ucd-snmp\bin>snmpgetnext -c public localhost enterprises.bea.wls.jvmRuntimeTable.jvmRuntimeEntry.jv mRuntimeHeapFreeC urrent output is : enterprises.bea.wls.jvmRuntimeTable.jvmRuntimeEntry.jv mRuntimeHeapFreeCurrent."a5976fd544677c07408aea43 3dd8ae84" = 18339632) Now the weblogic server SNMP is working fine as snmpgetnet is able to ping it and get values 4. Launch opensta and create a SNMP collector named "weblogic1". Enter IP address as localhost and query as "enterprises.bea.wls.jvmRuntimeTable.jvmRuntimeEnt ry.jvmRuntimeHeapFreeCurrent", port is default 161 and name it as "vmfree". 5. Create a test and add task "weblogic1". 6. Run test, During monitoring and even after test (that is stopped after some time) in the results the graph shows the value as 1 for the vmfree parameter. ---------------------------------------------------------------------- >Comment By: Daniel Sutcliffe (dansut) Date: 2005-05-10 17:35 Message: Logged In: YES user_id=19748 Issue merged into new bug# 1199408 ---------------------------------------------------------------------- Comment By: Ranjit Shewale (jcrvs) Date: 2003-05-05 05:32 Message: Logged In: YES user_id=721091 Dan, it sounds impossible to make you reach systems in our lab due to security issues. But is it possible for you to download a trial version of weblogic server from their wesbite ? ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2003-05-01 13:22 Message: Logged In: YES user_id=19748 Is there any way I can get access to SNMP on someones Weblogic server to reproduce this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=693443&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-10 21:31:53
|
Bugs item #1199408, was opened at 2005-05-10 17:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199408&group_id=10857 Category: SNMP Monitor Group: Behavioral Status: Open Resolution: None Priority: 5 Submitted By: Daniel Sutcliffe (dansut) Assigned to: Daniel Sutcliffe (dansut) Summary: Some SNMP queries always return wrong static answer Initial Comment: This bug report is replacing 2 other existing issues 768782 and 693443. It seems that certain SNMP queries willseem to be working - ie they return a value, however that value will be wrong and always the same. This may in fact be the query failing. The old reports we have are this: - all queries of WebLogic 7 SNMP properties return 1 - queries of Solaris 8 CPU return 12 Using snmpget or other similar tools worked correctly from the same machine in both cases. SF user nkame came up with this clue after investigating with a packet sniffer: "It seems that OpenSTA does't send pure OID as is, and does some magic. In my case I tried to get 1.3.6.1.4.1.2725.1.3.2, but OpenSTA was requesting sysUpTime.6.1.4.1.2725.1.3.2, that is it assumed my OID was relative to the MIB-2 root (1.3.6.1.2.1). Changing my requested OID to a "MIB-able" name (enterprises.2725.1.3.2) solved the problem. I still have from time to time a 12 appearing, perhaps due to a time-out or another non-handled error" Please add other reports of static and wrong values returned by SNMP to this bug report rather than opening any new report. The more information we have the sooner we can get to the bottom of this and fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199408&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-10 21:11:17
|
Bugs item #1199396, was opened at 2005-05-10 17:08 Message generated for change (Comment added) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199396&group_id=10857 Category: Architecture Group: Crash Status: Open >Resolution: Accepted Priority: 5 Submitted By: Daniel Sutcliffe (dansut) Assigned to: Daniel Sutcliffe (dansut) Summary: Starting Test fails with TestManager.exe failure Initial Comment: I'm not 100% sure what causes this but it seems to mostly happen when a network has gone away and come back or the IP address has changed. The error is simply that when starting a Test from the Commander the start will fail and the Microsoft dialog "TestManager.exe has encountered a problem and needs to close ..." appears. Clicking for more details shows that the omniorb304_rt.dll was involved as was winsock - more evidence that this is basically a network issue. Once this has happened you should be able to restart the Commander and the NameServer, the Test will probably then work fine if your network is stable again. ---------------------------------------------------------------------- >Comment By: Daniel Sutcliffe (dansut) Date: 2005-05-10 17:11 Message: Logged In: YES user_id=19748 More information on the actual circumstance of this error required. I currently can't reproduce this problem at will. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199396&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-10 21:09:14
|
Bugs item #1199362, was opened at 2005-05-10 16:14 Message generated for change (Settings changed) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199362&group_id=10857 Category: GUI Issue Group: Cosmetic Status: Open >Resolution: Accepted Priority: 5 Submitted By: Daniel Sutcliffe (dansut) Assigned to: Daniel Sutcliffe (dansut) Summary: If no NameServer, Architecture Manager gives Runtime Error Initial Comment: If the NameServer is not running and the user attempts to start the Architecture Manager from the Commmander Tools menu then a "Runtime Error!" will be generated due to access violations. A reasonable error ought to be given. If the NameServer has been previously running and the Architecture Manager used from the Commander then later running the Architecture Manager will display but with an empty network - this is probably the correct behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199362&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-10 21:08:32
|
Bugs item #1199396, was opened at 2005-05-10 17:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199396&group_id=10857 Category: Architecture Group: Crash Status: Open Resolution: None Priority: 5 Submitted By: Daniel Sutcliffe (dansut) Assigned to: Daniel Sutcliffe (dansut) Summary: Starting Test fails with TestManager.exe failure Initial Comment: I'm not 100% sure what causes this but it seems to mostly happen when a network has gone away and come back or the IP address has changed. The error is simply that when starting a Test from the Commander the start will fail and the Microsoft dialog "TestManager.exe has encountered a problem and needs to close ..." appears. Clicking for more details shows that the omniorb304_rt.dll was involved as was winsock - more evidence that this is basically a network issue. Once this has happened you should be able to restart the Commander and the NameServer, the Test will probably then work fine if your network is stable again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199396&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-10 20:28:27
|
Bugs item #703393, was opened at 2003-03-13 22:55 Message generated for change (Comment added) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=703393&group_id=10857 Category: GUI Issue Group: Inconvenience Status: Open >Resolution: Accepted Priority: 5 Submitted By: Danny Faught (faught) Assigned to: Daniel Sutcliffe (dansut) Summary: Can't get Properties pane when Show Properties button gone Initial Comment: 1. Create a test and open it in the test pane in Commander (I'm using OpenSTA 1.4.1 on Windows 2000). 2. Close the Properties pane. 3. Tear off the toolbar with the Show/Hide Properties button so it's separated from the parent window. 4. Click the X on the toolbar to close. There is now no Properties pane and no button to bring it back. This can be confusing and distressing to the user. The workaround is to close the test and reopen it. The button reappears when I do this. I'm thinking that either the toolbar on the main window should reappear when the floating toolbar is closed, or there shouldn't be a close button on the floating toolbar at all. There may be a similar issue with the Compile/Start/Stop/Kill toolbar. ---------------------------------------------------------------------- >Comment By: Daniel Sutcliffe (dansut) Date: 2005-05-10 16:28 Message: Logged In: YES user_id=19748 Addititionally to this: sometimes when starting viewing a Test the TestPlugin Configuration tab does not seem to initialize properly and the Properties button and pane don't appear. Changing to any other tab and back to the Configuration tab seems to fix the problem. This only seems to happen occasionally - usually after a reboot. Although the initial problem is really fixed on XP, this whole area should be looked at and the ability for these additional toolbars to be floated removed. ---------------------------------------------------------------------- Comment By: Daniel Sutcliffe (dansut) Date: 2003-05-01 13:30 Message: Logged In: YES user_id=19748 On WinXP the X button in the undocked props toolbar does not work (shouldn't be there?). Double clicking on header returns bar to being docked. This needs checking on other versions of Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=703393&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-10 20:14:12
|
Bugs item #1199362, was opened at 2005-05-10 16:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199362&group_id=10857 Category: GUI Issue Group: Cosmetic Status: Open Resolution: None Priority: 5 Submitted By: Daniel Sutcliffe (dansut) Assigned to: Daniel Sutcliffe (dansut) Summary: If no NameServer, Architecture Manager gives Runtime Error Initial Comment: If the NameServer is not running and the user attempts to start the Architecture Manager from the Commmander Tools menu then a "Runtime Error!" will be generated due to access violations. A reasonable error ought to be given. If the NameServer has been previously running and the Architecture Manager used from the Commander then later running the Architecture Manager will display but with an empty network - this is probably the correct behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199362&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-10 19:56:26
|
Bugs item #1084539, was opened at 2004-12-13 12:29 Message generated for change (Settings changed) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1084539&group_id=10857 Category: Architecture Group: Fatal Error Status: Open >Resolution: Accepted Priority: 7 Submitted By: Daniel Sutcliffe (dansut) >Assigned to: Daniel Sutcliffe (dansut) Summary: Name Server can be unstable and diagnostics are not obvious Initial Comment: This bug is being created to collect together all the existing bugs that basically amount to the fact that the OpenSTA Name Server is generally unstable - specifically at startup - and that the diagnostics that it returns when it fails in many cases are unhelpful and don't point to the true source of the issue - which is usually an external or configuration problem. The creation of this bug will be followed by the closing of bugs: 703897: name server aborts on startup - external issue 676320: name server unexpectedly exit - external issue 642369: fail restart nameserver 591997: Name server crashes 439661: Badly config'd name server will crash - config although these bugs are closed please reference for more info. Please don't create any more bugs with reference to the name server failing to start or crashing - instead add specific information here about your situation. Me too's aren't necessary unless you have some new info to add. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1084539&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-10 19:55:57
|
Bugs item #1095283, was opened at 2005-01-03 16:56 Message generated for change (Settings changed) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1095283&group_id=10857 Category: Architecture Group: Behavioral Status: Open >Resolution: Accepted Priority: 5 Submitted By: Daniel Sutcliffe (dansut) Assigned to: Daniel Sutcliffe (dansut) Summary: Starting non-existent Test using TestInit fails badly Initial Comment: If a Test that does not exist in your Repository is attempted to be started using the command line tool TestInit will look like a test is started. An error message should be reported. It will also creating a looping TestManager that can only be killed manually and this will create directories in the Repository for Test results for the non-existent Test - which creates confusing non-sensical displays in the Commander. eg. TestInit -start -T NONSENSE -S 10 Will create a Repository/Tests/Nonsense dir with a dated result dir below this. If the Test Nonsense never existed this will create a mess in the Tests tree in the Commander. To recover from this stituation the TestManager.exe process must be ended from the Windows Task Manager and the Nameserver should be restarted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1095283&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-10 19:46:32
|
Bugs item #1083975, was opened at 2004-12-12 14:44 Message generated for change (Comment added) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1083975&group_id=10857 Category: Script Language Group: Crash Status: Open >Resolution: Works For Me Priority: 5 Submitted By: Daniel Sutcliffe (dansut) Assigned to: Daniel Sutcliffe (dansut) Summary: Concatenating large SCL strings can cause compiler to crash Initial Comment: Concatenating VERY large SCL strings can cause the compiler to crash and leave invalid (incomplete) compiled TOF files in place. This is usually done to work around the SCL limits on max variable size - specifically when dealing with multipart/form-data file uploads. In fact, recent changes mean the SCL generated by a recording may show this problem. An example of the problem code is ... ,BODY "A very very long sequence of chars" & ... "probably more than 50K worth" + & "Another huge string of similar size to" & ... "cause the issue" There does seem to be a workaround. Place your BODY contents in character variables and then concatenate thus: ... SET BODYCONT1="A very very long sequence of chars" & ... "probably more than 50K worth" SET BODYCONT2="Another huge string of similar size to" & ... "cause the issue" ... ,BODY BODYCONT1 + BODYCONT2 More investigation required to find actual boundaries and cause of this problem. ---------------------------------------------------------------------- >Comment By: Daniel Sutcliffe (dansut) Date: 2005-05-10 15:46 Message: Logged In: YES user_id=19748 Quite a few fixes in this area and I now can't reproduce - leaving the bug open though just to let people know it is possible. If you see this issue on an OpenSTA installation newer than 1.4.2 then please comment on this bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1083975&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-10 19:40:42
|
Bugs item #1083968, was opened at 2004-12-12 14:31 Message generated for change (Settings changed) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1083968&group_id=10857 Category: Script Language Group: Behavioral Status: Open >Resolution: Accepted Priority: 5 Submitted By: Daniel Sutcliffe (dansut) Assigned to: Daniel Sutcliffe (dansut) Summary: Actual max variable size seems to vary dependent on content Initial Comment: The SCL compiler is documented to put a limit of 65535 characters in its character variables. When this limit is exceeded the compiler reports the error "maxstrlen". The issue here is that the actual number of characters in a string can actually be less than 65535 before "maxstrlen" is reported by the compiler. The actual max size of a variable seems to be related to the content of the variable - specifically the use of SCL mnemonics. More investigation needs doing to work out the exact details of this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1083968&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-10 18:00:30
|
Bugs item #1199254, was opened at 2005-05-10 14:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199254&group_id=10857 Category: Installation Group: Inconvenience Status: Open Resolution: None Priority: 5 Submitted By: Daniel Sutcliffe (dansut) Assigned to: Daniel Sutcliffe (dansut) Summary: Bad failures due to WinXP Home limitations Initial Comment: OpenSTA will install and basically work on Windows XP Home - however there are limitations to the toolsets functionality. This bug is not really to fix the limitations (although if it is possible then it will be done), instead it is to make sure that the XP Home limitations are clearly documented and that the OpenSTA tools will fail cleanly, or not allow at all, the limited features. The limitations we know of now are: - distributed testing does not work. - NT Perfromance Monitor Collectors require installation of an optional component. - Possible that certain XP users cannot run Modeler, etc. (previously reported but deleted bug). The is also an FAQ page that deals with these limitations: http://portal.OpenSTA.org/faq.php?topic=WinXpHomeLimitations If you know of any other limitations please add them here or to the FAQ. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199254&group_id=10857 |
32 messages has been excluded from this view by a project administrator.
