SlickEdit Community
SlickEdit Product Discussion => SlickEdit® => Topic started by: RobFreundlich on September 14, 2006, 04:51:15 PM
-
I am trying to use the Quick Extract Method feature in a Java file. When I select my lines of code and then right-click and pick "Quick Extract Method", the C/C++ Compiler Properties dialog displays. As I have no C/C++ compilers on my system, it has no default configuration, and I cannot proceed.
What's the proper setup here for a Java-only environment?
I can create a new configuration (called rsf-test) and pick a C++ header file from the available ones, but if I then try to run the feature, I get screwy results. Sometimes the method will be successfully extracted, but sometimes SlickEdit will just hang, using 100% of CPU. Is that because I don' t have an actual C/C++ compiler, or is this feature just a bit buggy for Java?
-
Hey Rob.
Thanks for the problem report(s).
The issue with the C/C++ Compiler Configuration dialog coming up is a known bug. It traces back to the fact that the original refactoring work was done for C++ and we used some shared routines to check if everything was initialized up front. This will be fixed in the next version of SlickEdit. Your work-around of creating a fake compiler configuration and making it the default should get you around this obstacle.
With respect to the hang -- we have not seen this problem. I recommend that you send a reproducable example into SlickEdit support if you see any such problem again with Quick Extract Method.
-
With respect to the hang -- we have not seen this problem. I recommend that you send a reproducable example into SlickEdit support if you see any such problem again with Quick Extract Method.
I've found a very minimalist situation that fails. Check this out:
public class ExtractMethodFails
{
public ExtractMethodFails()
{
}
/**
*/
public void start()
{
// --- START HERE
// --- END HERE
}
}
In the above class, selecting the lines from "// --- START HERE" to "// --- END HERE" and running Quick Extract Method will hang my system every time. However, in the following class, Quick Extract Method works just fine:
public class ExtractMethodWorks
{
public ExtractMethodWorks()
{
}
public void start()
{
// --- START HERE
// --- END HERE
}
}
I whittled this down from a much more complex example. Ultimately, it appears as though the existence of a Javadoc comment on the start() method is what causes the hang! That's so bizarre that I have to post it here to see if folks can reproduce it before I send it in to support.
Would someone else please take these classes and try to verify my findings?
Thanks!
-
I just had another developer here verify this. I'm on 11.0.2, and he's on 11.0.1, and it happens on both versions. He showed me Ctrl-Alt-Shift-F2 to stop the script, and I was able obtain the following stack trace:
Slick-C STACK TRACE ******************************
Created on 9/15/2006 at 9:21:11 (314 ms)
Edit module and type "st -f <offset>" to get the
run-time error position
error code=-3020
Break key pressed. Macro halted
cutil.ex 9057 _in_comment(0) p_window_id: 13 p_object: OI_FORM p_name:
quickrefactor.ex 4838 static(9) p_window_id: 13 p_object: OI_FORM p_name:
quickrefactor.ex 8108 refactor_quick_extract_method() p_window_id: 13 p_object: OI_FORM p_name:
Looking at quickrefactor.ex (running st-f 4838), I see that it's in this loop:
while (p_line > non_blank_line) {
if (_in_comment()) {
up();
continue;
}
_str line='';
get_line(line);
if (line=='') {
break;
}
}
That's interesting. It's as if the _in_comment()/up() combination isn't working so it's getting stuck in the comment ... Sure enough, if I put a blank line between the comment and the start() method, the extract works. So at least now I have a workaround and a way to get out of the hang if it occurs.
With regard to sending things to support, is it enough to post it here, or should I send email to support@slickedit.com?
-
You could try this tiny patch:
quickrefactor.e - find_new_method_insertion_point() [line 992] (see the // HS2: comment)
// loop until we find a blank line outside of a comment
while (p_line > non_blank_line) {
if (_in_comment()) {
up();
continue;
}
_str line='';
get_line(line);
if (line=='') {
break;
}
// HS2: go up if it's still a non-blank line
up();
}
The reason is that _in_comment() already returns false on the (non-blank) line containing '/**' due to the begin_line() above the loop...
HS2
-
That solves it. Thanks!