SlickEdit Community
SlickEdit Product Discussion => SlickEdit® => Topic started by: DaveyC on January 20, 2011, 03:44:09 AM
-
Invalid argument
filetypemanager.ex 3879 _edit_file_type_map_form._ctl_ok.\x{2eb}(<empty>,C:\Documents and Settings\davcra01\My Documents\My SlickEdit Config\15.0.1\ftp\FTS1\FUW110.WORK.C\*,C/C++)
p_window_id: 378
p_object: OI_COMMAND_BUTTON
p_name: _ctl_ok
dlgeditv.ex 6706 show(-modal -xy _edit_file_type_map_form,<empty>,C:\Documents and Settings\davcra01\My Documents\My SlickEdit Config\15.0.1\ftp\FTS1\FUW110.WORK.C\*,C/C++)
p_window_id: 311
p_object: OI_COMMAND_BUTTON
p_name: _ctl_edit_pattern_btn
filetypemanager.ex 3177 filetypemanager:editExtensionlessFileSetting(<empty>) p_window_id: 311 p_object: OI_COMMAND_BUTTON p_name: _ctl_edit_pattern_btn
filetypemanager.ex 2978 _manage_advanced_file_types_form._ctl_edit_pattern_btn.\x{2cc}() p_window_id: 308 p_object: OI_TREE_VIEW p_name: _ctl_patterns_tree
-
Can you also post the steps you performed to produce this stack? Thanks!
-
Sure...
- Open FTP Client and list mainframe source library data set. Download C file (which defaults to PL/1)
- Document->Select Mode->C/C++
- Select "map all extensionless files in ..." in the "map files like this" window
- Tools->Options->Extensionless Files Manager - try to edit the pattern that has just been inserted - STACK!
Path name is C:\Documents and Settings\davcra01\My Documents\My SlickEdit Config\15.0.1\ftp\FTS1\FUW110.WORK.C
I was excited when I first saw the Extensionless File Manager because all mainframe source files are extensionless. I've been using a
customized version of the userSelectEditMode callback to automatically set the select mode prior to the new Extensionless File Manager.
Unfortunately EFM seems to be broken.
If I take the first 3 steps above and then modify the buffer it reverts back to PL/1 mode. I've attached my cmmode.e which works fine.
-
Thanks! I was easily able to reproduce this. Not that it affects this defect, but what were you going to change the pattern to?
At what point does it revert to PL/1? After a save? After you close and reopen the file? This part I can't reproduce. When I remove the extension from a C++ file and open it, the document mode is set to plain text. Despite getting the stack in the EFM, all other extensionless files are opened as C++ after I have done the mapping.
-
A fix for this bug has been included in the cumulative hot fix. To download the latest hot fix, go to http://www.slickedit.com/index.php?option=com_content&view=article&id=260&Itemid=41.
Thanks for the bug report!
-
Scott - not sure if Sandra has already fixed this but it reverts to PL/1 as soon as I modify the buffer.
Change 1 character and BANG - I'm in PL/1! I like PL/1 but not that much ;^)
-
Sorry Scott I didn't answer you question in my reply. I wanted to change the pattern to **/*.C/** to use the EFM to map
all MVS data set names to *.c files. I'm not sure if that's the correct syntax. The EFM is a very useful feature for mainframe
customers who use the FTP client to edit their source code. I've moved on to RDz with the core plugin for most of my work
these days and it has a nice mapping feature. I would like to reproduce this in the EFM.
-
The pattern you provided would match all files in a directory ending in ".C". Is that what you were after?
Please let us know if this is working properly after you apply the hot fix. Thanks!
-
Applied the hotfix and still getting the stack.
-
Argh, you're right. I'm sorry, I should have stated that the hot fix takes care of the cause of the stack, so that future users who use the "Map files like this" dialog don't get into that state. But you're already in the state where you'll get one. You should be able to delete and then re-add the item in the EFM. My apologies.
-
ok, that fixed the stack. My problems are this.
- The EFM does not work opening extensionless files using the FTP client (even with the right patterns)
- After manually changing the select mode to C and editing the buffer, C code reverts to PL/1 mode
-
What pattern(s) are you using in the EFM? If it's easier, you can just take a screenshot of the EFM and post it here. If you open those files through another method (the command line, the open tool window, etc.), do they open with the correct mode?
-
It only happens using the FTP client and I very much suspect when the host type is MVS.
-
Would it be possible for you to send me a couple of the files that this happens on? You can post them here or send them to sgaskins (at) slickedit (dot) com.
Thanks!
-
ok, I've started looking at this again and it seems that the EFM is not called when the buffer is an MVS DataSet and FTP. BTW, I found a bug in the code, here's the fix.
_str _getFileTypeFromQualifier(_str buf_name,_str dsname='')
{
if (dsname=='') {
if (buf_name=='' || !_DataSetIsFile(buf_name)) return('');
dsname=_DataSetNameOnly(buf_name);
}
_str dataset_type = lowcase(get_extension(dsname,true)); // TRUE WAS MISSING SO NO DOT COMING BACK (DEFAULT)
if (dataset_type==".asm") {
return("asm390");
}
if (substr(dataset_type,1,1)==".") {
return(substr(dataset_type,2));
}
return("");
}
Also, how do I stop SlickEdit from deleting the temporary file from the FTP directory when the buffer is closed? I'm thinking I could use that as a project directory for tagging when using FTP on MVS mainframe projects.
-
OK, just wondering if this got missed. The current status is that the EFM is currently broken when opening MVS data set files via FTP. It's so bad that I can't roll out SE to members of my team.
-
That's no good. I'll check on this and let you know what's going on.
-
I have a possible solution for you. I'd like you to try it out and see if it works.
The problem is that we are auto-detecting file types for dataset files that were retrieved with FTP. There is a way to turn this auto-detection off, but it doesn't work quite right, so I've made a code change as well.
- Back up your existing copy of stdcmds.e. It can be found in <INSTALLDIR>/macros./li]
- Copy the attached stdcmds.e into the macros dir. Load it using Macro > Load Module.
- Set VSLICK390AUTOFILETYPE to 0. On Windows, I had to log out and then log back in for this change to show up in Slickedit.
See if the problem is still there. I think this is a step forward, though I'm not sure if it's a step all the way.