Things broken in Studio 2.4

DHawthorne

This is what I have noticed in just a day's use, I hope there's not more.

1) Search-and-replace greys out the "Replace in Selection" option if the selection is small enough to automatically fill the search box. Typing a smaller search parameter in the box does not un-grey the option. If you select a large enough block that the search parameter is not automatically filled (welcome change, by the way), it works as expected. It makes sense that you shouldn't do a replace on a selection if the search parameter is the entire selection, but it needs to reset the dialog if you change the search parameter so this is no longer the case. It makes it impossible to fix a repeated typo in smaller selections in one shot.

2) The "Start at top of file" checkbox in all search or replace dialogs doesn't work. It always searches from the cursor position no matter what.

3) Options used in a previous search dialog are no longer retained the next time you use it. I'm ambivalent on this one, because sometimes I found this retention annoying - however, I've gotten used to it and find the omission more annoying.

Dries Kaspers

I have found that the diagnostics window keeps on refreshing even when there are no more events to display. this wasn't the case with 2.3

jjames

Try this one on for size:

ERROR: (0): C10580: Internal Error: Major system error occurred during code generation.

I've rebooted several times and still am getting this error. Can't compile any file. I'm afraid to work on my client files now. Luckily I got this while doing R&D work. Obviously going to have to uninstall this one.

jjames

Nevermind - error in my behalf. Sorry.

[Deleted User]

Search - Search and Replace

DHawthorne wrote:

This is what I have noticed in just a day's use, I hope there's not more.

1) Search-and-replace greys out the "Replace in Selection" option if the selection is small enough to automatically fill the search box. Typing a smaller search parameter in the box does not un-grey the option. If you select a large enough block that the search parameter is not automatically filled (welcome change, by the way), it works as expected. It makes sense that you shouldn't do a replace on a selection if the search parameter is the entire selection, but it needs to reset the dialog if you change the search parameter so this is no longer the case. It makes it impossible to fix a repeated typo in smaller selections in one shot.

2) The "Start at top of file" checkbox in all search or replace dialogs doesn't work. It always searches from the cursor position no matter what.

3) Options used in a previous search dialog are no longer retained the next time you use it. I'm ambivalent on this one, because sometimes I found this retention annoying - however, I've gotten used to it and find the omission more annoying.

I have verified item 3 as being an issue from the get go and reported it to tech support on Friday.

It is nice to add features and fix bugs, but we should not be going backwards. I hope we don't need to wait long for a simple patch.

On the positive side, many nagging issues have been resovled. Anyone try the new firmware yet? The web interface continues to improve.

HARMAN_guy.minervini

The "selection" option isn't enabled if you don't select the CRLF at the end of the line on purpose. The selection option is enabled only if your selection spans more than one line. The reason is because alot of people start their replace by making a selection first. If you double-click on a word you want to replace and hit Ctrl+H (the default for Replace), the word you selected is put in the "Find What" textbox. If we turn on the "selection" box, there will be exactly one match, the user's selection... which clearly is not what the user intended (functionally). In general, searching in a selection occurs when the selection is more than one line.

DHawthorne

guy.minervini wrote:

The "selection" option isn't enabled if you don't select the CRLF at the end of the line on purpose. The selection option is enabled only if your selection spans more than one line. The reason is because alot of people start their replace by making a selection first. If you double-click on a word you want to replace and hit Ctrl+H (the default for Replace), the word you selected is put in the "Find What" textbox. If we turn on the "selection" box, there will be exactly one match, the user's selection... which clearly is not what the user intended (functionally). In general, searching in a selection occurs when the selection is more than one line.

I regulary copy and paste repetitive code blocks, so if I make a typo in one spot, it propogates to the entire segment. So I was in the habit when this happened of highlighting the entire segment, then search/replacing the typo. In other cases, you may have to change a single variable in just one segment to an indexed array - same applies. Or you need to change one variable in an entire section, but not the rest of the code. By trying to make this idiot proof, you broke a very helpful feature. Saying "always include the line end" means I can't select part of a DEV array that doesn't span lines, or a segment of it that doesn't. I think your users are smart enough to know when they highlight one word that it's not effective to "replace" it in a search. At least I now know the workaround, but I liked it better the old way.

HARMAN_guy.minervini

Dave, I'm having a little trouble visualizing what you're trying to do.
Can you email me a screen shot or two?
My email is guy.minervini@amx.com

HARMAN_icraigie

And the Notification viewer not working sucks too! Fills up the text box then won't scroll down as more events come in - just sits there flashing.

Joe Hebert

icraigie wrote:

And the Notification viewer not working sucks too! Fills up the text box then won't scroll down as more events come in - just sits there flashing.

I don?t find that to be the case unless one of the items in the text box is selected. The Notification window works the same as always except that it does keep on flashing even when new events aren?t coming in. And as Dries already pointed out the Diagnostics window does the same thing. It makes it a little tough on the eyes for sure.

DHawthorne

guy.minervini wrote:

Dave, I'm having a little trouble visualizing what you're trying to do.
Can you email me a screen shot or two?
My email is guy.minervini@amx.com

I can't for the life of me remember the code snippet I was working on that was giving me the fits with this, but here is a similar example. You will see in that screenshot I have only part of a char array highlighted - if I want to change all the :04: on those strings to :05: in only the highlighted strings, I can't use the replace in slelection feature. Sure, I could highlight the whole line and then go back and revert the ones I don't want to, or I could manually edit them, but I am in the habit of using replace for this kind of things. This is a limp example, because it's not that difficult to do another way to make it work in this case. It may be, now that I know it's the EOL causing it, that it's not such a big deal after all. But the code I was working on when I found the issue was fairly convoluted, and I was annoyed to have to replace my changes manually. My point is that as soon as I change the Find field so that it no longer consists of the entire selection, the replace in selection option should become available.

HARMAN_icraigie

Joe Hebert wrote:

I don?t find that to be the case unless one of the items in the text box is selected. The Notification window works the same as always except that it does keep on flashing even when new events aren?t coming in. And as Dries already pointed out the Diagnostics window does the same thing. It makes it a little tough on the eyes for sure.

Yup - that's what's happening - man is that annoying!

pauld

"Build Active System" weirdness...

I use the "Build Active System" button to get all the code in a system complied, and this has all ways worked well for me in previous versions of Netlinx Studio.

I just upgraged Netlinx Studio to the new 2.4 version and now when i open a workspace, open the master code, make a change, then press "Build Active System" the entire Netlinx Studio Frezzes like it locked up. After about 10 Seconds the screen refreshes and the compile contiunes fine. If i don't make any changes, but run the complier then there is no delay.

Also i have noticed that the loading of workspaces takes much longer than before, as well as the saving of files. Earlier version of Netlinx Studio never took this long and were very quick as far as loading and saving source code. The new version is just very slow at these tasks.

Has anybody else noticed these delays?

DHawthorne

I've notice the white screen and temporary freeze while saving files. Since I have the auto-save on, it's quite obvious when it happens while you are typing. This stands to reason though, storing all the folding data means there is more to save. It could probably stand some optimizaion (assuming there is anything to optimize).

Marc Scheibein

pauld wrote:

Also i have noticed that the loading of workspaces takes much longer than before, as well as the saving of files. Earlier version of Netlinx Studio never took this long and were very quick as far as loading and saving source code. The new version is just very slow at these tasks.

Has anybody else noticed these delays?

I agree - opening/closing/saving source and workspaces takes noticable longer as in Studio 2.3...

Joe Hebert

I agree with everything that pauld wrote in post #13 of this thread.

I got a stopwatch and did some testing with a project. Mileage may vary.

I double click the workspace file and Netlinx Studio 2.4 takes about 4 seconds to launch and with 2.3 it was pretty much instantaneous. While I?m waiting CPU usage is pegged at 100%.

I then double click the main source code file in the project (135K byte file with 4800 lines) and it takes almost 4 seconds to open and the CPU gets pegged at 100%. Again, with 2.3 I never noticed having to wait at all.

Next I maximize the source code file and grab the scroll bar and try to drag it down quickly to the end of the file. While I?m doing that the scroll bar freezes and the CPU gets pegged again. After it unfreezes it moves down some more and then locks again. After about 4 seconds I?m able to reach the end of the file.

Once I?ve scrolled through the entire file once I can scroll up and down without any problems. But as soon as I ?dirty? the file (by just adding a space on a blank line) I can?t scroll though the entire file without it freezing again. And if I close that file, reopen it (wait 4 seconds again) and then try to scroll to the bottom I have to wait again to get to the bottom.

Next I do a Build Active System. The status window opens immediately and it compiles 762K in about 11 seconds. I close the status window and I ?dirty? the main source code file and then do another Build Active System. The screen freezes and after 8 seconds the status window opens and the code compiles in 11 seconds. Total compile time 19 seconds. During this entire process the CPU is pegged at 100%.

I?ve always found Netlinx Studio to be one of the fasted AMX programs and I?ve been spoiled with the speed. I?d like to revert back to Netlinx Studio 2.3 until someone figures out who?s putting the brakes on version 2.4. Is Netlinx Studio 2.3 on the AMX web site anywhere?

Thanks,

Joe Hebert

Here is a follow up to my previous post. I reverted back to Netlinx Studio 2.3 and performed the same tests with the same project that I did with Netlinx Studio 2.4. Here are the results:

Open workspace:
NS 2.4 ? 4 seconds
NS 2.3 ? a little over 1 second

Open main source code file (135K byte file with 4800 lines)
NS 2.4 ? 4 seconds
NS 2.3 ? less than 1 second (reflexes aren?t fast enough)

Grab scroll bar and drag to bottom of file:
NS 2.4 ? 4 second delay
NS 2.3 ? No delay

?Dirty? main source code file (by adding a space on blank line)
Grab scroll bar and drag to bottom of file:
NS 2.4 ? 4 second delay
NS 2.3 ? No delay

Build Active System
NS 2.4 ? 11 seconds
NS 2.3 ? less than 5 seconds

?Dirty? main source code file (by adding a space on blank line)
Build Active System
NS 2.4 ? 19 seconds
NS 2.3 ? less than 5 seconds

I was also surprised by a significant tkn file size increase. Here are two projects compiled with 2.3 and 2.4. Compile with Debug Info was turned on for both projects.

Project 1 compiled tkn file
NS 2.4 ? 434,910 bytes
NS 2.3 ? 395, 313 bytes
File size increase with 2.4 = 10%

Project 2 compiled tkn file
NS 2.4 ? 1,105,360 bytes
NS 2.3 ? 757,143 bytes
File size increase with 2.4 = 46%

There is good news. The 2005 Chicago White Sox are World Champions! Sorry Cub fans?Not!

[Deleted User]

To add to the misery:

The Axcess compiler is broken again. Seems to be the same 'introduced problem with WAITs' that was in - I'm going on memory here - Studio2 V1.1. The symptoms are identical: a section of code that executes after a WAIT (in this case removing commands from a buffer and sending them to an RS232 port) never executes.
I've also gone back to V2.3 - though this hasn't fixed my other problem:

As soon as I installed V2.4 all of the older AMX programs on my laptop stopped working: The DOS programs (eg Axcessx) and the 16 bit windows programs (eg OLDesign.) This may just be a problem with my laptop (doesn't seem to be an issue on my home PC.) Has anyone else seen this problem?

Dries Kaspers

Same here on OLDesign not working anymore, reinstalling it does not fix it... very annoying.

Thomas Hayes

What type of laptop are you using dickster? I had a few issues with my laptop and it tooksome real tweaking to correct.

DHawthorne

Dickster wrote:

To add to the misery:

The Axcess compiler is broken again. Seems to be the same 'introduced problem with WAITs' that was in - I'm going on memory here - Studio2 V1.1. The symptoms are identical: a section of code that executes after a WAIT (in this case removing commands from a buffer and sending them to an RS232 port) never executes.
I've also gone back to V2.3 - though this hasn't fixed my other problem:

As soon as I installed V2.4 all of the older AMX programs on my laptop stopped working: The DOS programs (eg Axcessx) and the 16 bit windows programs (eg OLDesign.) This may just be a problem with my laptop (doesn't seem to be an issue on my home PC.) Has anyone else seen this problem?

Ugh. That's a major issue - it will break every project I have (as it did with the original bug). If Engineering is lurking here (and I know you are), you had best hotfix this one immediately, whether anything else is fixed or not.

DHawthorne

On that note - what was the date stamp on the last version of 2.3? The only older revision I can find in my archives is dated 4/7 2003 - and I don't think that can be 2.3. Next question - does anyone have a copy? I don't see it on the AMX site anymore, and I can't afford to deal with the broken WAIT bug again. It cost me days last time around.

HARMAN_guy.minervini

I suspect Joe's issues are mostly side effects of new features, e.g. the new Unicode functions were implemented as NetLinx code in the NetLinx.axi - that's the reason for the bigger compile sizes;
The slower open times may be due to the new feature where the code folding state is remembered; etc...

HARMAN_guy.minervini

I wrote some Axcess code to test the WAIT bug, works just fine:
PROGRAM_NAME='AxcessWaitTest'
DEFINE_DEVICE

RELAY = 7

DEFINE_PROGRAM

WAIT 20
{
[RELAY,1] = ![RELAY,1]
}


(* end *)

If anyone has code that can demonstrate the alleged bug please email it to guy.minervini@amx.com, with instructions for duplicating it.

Thanks in advance...

[Deleted User]

AMX Tech Support

Those of you with problems, my experience is to take them directly to AMX tech support for verification. Thanks to Guy for working on this one.

HARMAN_guy.minervini

Regarding problems with our old Borland-based OWL 16-bit apps, I'm unable to duplicate the issue on XP Pro - they seem to run fine.

What OS are you using? There were some issues with OWL and Windows 2000, that were fixed in in one of the W2K service packs. See http://support.microsoft.com/default.aspx?scid=kb;en-us;299770

DHawthorne

guy.minervini wrote:

I wrote some Axcess code to test the WAIT bug, works just fine:
PROGRAM_NAME='AxcessWaitTest'
DEFINE_DEVICE

RELAY = 7

DEFINE_PROGRAM

WAIT 20
{
[RELAY,1] = ![RELAY,1]
}


(* end *)

If anyone has code that can demonstrate the alleged bug please email it to guy.minervini@amx.com, with instructions for duplicating it.

Thanks in advance...

I don't think it showed up in a code block like that. As I recall, it was repeated named waits, such as you might use to send command packets from a queue with a serial device, that caused the problem. The named wait never triggered if it was called a second time and the first hadn't triggered yet, effectively locking up the serial device - nothing would go out. Mind you, I haven't seen it in a 2.4 compile myself, I'm just having a bit of a knee-jerk reaction to a report of it being back because it cost me so much last time. If it's any help, it was the first release of Studio 1.2 that had the problem.

HARMAN_guy.minervini

DHawthorne wrote:

The named wait never triggered if it was called a second time and the first hadn't triggered yet...

That is one of the features of a named wait, but it shouldn't lock up the device.

Please let me know if you find the offending code...

[Deleted User]

guy.minervini wrote:

Regarding problems with our old Borland-based OWL 16-bit apps, I'm unable to duplicate the issue on XP Pro - they seem to run fine.

What OS are you using? There were some issues with OWL and Windows 2000, that were fixed in in one of the W2K service packs. See http://support.microsoft.com/default.aspx?scid=kb;en-us;299770

Guy,

My work laptop runs Win XP Pro SP1: but my home PC runs the same OS and doesn't show this problem (though on my home PC the offending programs were installed after V2.4.)

DHawthorne

guy.minervini wrote:

That is one of the features of a named wait, but it shouldn't lock up the device.

Please let me know if you find the offending code...

You misunderstand me. I know how it supposed to work, I use them in every serial driver I've ever written. I'm saying it never triggered if once blocked by a pending wait with the same name. The way it's supposed to work is once the pending wait times out, it triggers the code block, disregarding any new waits of the same name until that time. When the wait time expires, it's still supposed to trigger the code block. But that wasn't ever happening if another wait was initiated before the timeout. It didn't lock up the master, the wait just didn't fire. In effect, this took the serial device off line. The code in the wait never happened, the wait never timed out. Subsequent waits of the same name weren't being disregarded, they were resetting the wait ad infinitum.

And again, I haven't confirmed this bug is back, just reacting to the possibility. But that was the form it took last time, and the code segment you listed wouldn't have been affected. Try the same thing with your wait named.

GSLogic

Here's a strange one:

I opened a file then collapsed all levels so I see all the function names, but the function I was looking for was gone. The top line of the function was missing from the code but Studio 2.4 still compiled okay.

I knew the line of code was still there just not visable, because if I tryed to add it back Studio would give me an error.

After closing the file and reopening it, the function name reappeared.