[jira] [Created] (NETBEANS-997) Unable to download and create GlassFish server

2018-06-25 Thread Rick Hegarty (JIRA)
Rick Hegarty created NETBEANS-997:
-

 Summary: Unable to download and create GlassFish server 
 Key: NETBEANS-997
 URL: https://issues.apache.org/jira/browse/NETBEANS-997
 Project: NetBeans
  Issue Type: Bug
  Components: serverplugins - GlassFish
Affects Versions: 8.2, 9.0
 Environment: Product Version: Apache NetBeans IDE Dev (Build 
incubator-netbeans-release-302-on-20180517)
Updates: Updates available
Java: 1.8.0_172-ea; Java HotSpot(TM) 64-Bit Server VM 25.172-b03
Runtime: Java(TM) SE Runtime Environment 1.8.0_172-ea-b03
System: Windows 10 version 10.0 running on amd64; Cp1252; en_US (nb)
User directory: C:\Users\johndoe\AppData\Roaming\NetBeans\dev
Cache directory: C:\Users\johndoe\AppData\Local\NetBeans\Cache\dev
Reporter: Rick Hegarty
 Attachments: installGlassfish1.png, installGlassfish2.png

[1] Add a Glassfish server: *Services Panel > Servers >* right-click *> Add 
Server... > GlassFish Server > Next >*

[2] On the *Add Server* screen:
 * In *Installation Location* enter a valid directory name that does not exist. 
 * Check the _I have read_ checkbox.
 * Click *Download Now...* and then select _Glassfish Server 4.1.1_ as the 
server to be downloaded. 
 * See attached screenshot *installGlassfish1.png*

[3] The download appears to be successful but there is an error at the bottom 
of the *Add Server Instance* window: *! Does not exist.* See attached 
screenshot *installGlassfish2.png*

 [4] The target folder does not get created. Also, if an empty target folder is 
pre-created the same error occurs, and the target folder remains empty.

[5] This error occurs with both NB 8.2 and NB 9.0 RC1.

[6] Priority is minor since the simple workaround is to download Glassfish 
first outside of NetBeans, and then select that downloaded folder within the 
*Add Server* wizard.

[7] Possible duplicate of NETBEANS-965 ("does not load GlassFish"), but there 
is no description for that bug and the screenshot information is in Russian.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Created] (NETBEANS-996) java.util.regex.PatternSyntaxException: Unexpected internal error near index 7

2018-06-25 Thread chopin xiao (JIRA)
chopin xiao created NETBEANS-996:


 Summary: java.util.regex.PatternSyntaxException: Unexpected 
internal error near index 7
 Key: NETBEANS-996
 URL: https://issues.apache.org/jira/browse/NETBEANS-996
 Project: NetBeans
  Issue Type: Bug
Reporter: chopin xiao


\.idea\
   ^
at java.base/java.util.regex.Pattern.error(Pattern.java:2010)
at java.base/java.util.regex.Pattern.compile(Pattern.java:1779)
at java.base/java.util.regex.Pattern.(Pattern.java:1422)
at java.base/java.util.regex.Pattern.compile(Pattern.java:1082)
at 
org.eclipse.jgit.ignore.internal.Strings.convertGlob(Strings.java:352)
at 
org.eclipse.jgit.ignore.internal.WildCardMatcher.(WildCardMatcher.java:66)
at 
org.eclipse.jgit.ignore.internal.PathMatcher.createNameMatcher0(PathMatcher.java:145)
at 
org.eclipse.jgit.ignore.internal.PathMatcher.createPathMatcher(PathMatcher.java:127)
at 
org.eclipse.jgit.ignore.FastIgnoreRule.(FastIgnoreRule.java:114)
at org.eclipse.jgit.ignore.IgnoreNode.parse(IgnoreNode.java:114)
at 
org.eclipse.jgit.treewalk.WorkingTreeIterator$PerDirectoryIgnoreNode.load(WorkingTreeIterator.java:1166)
at 
org.eclipse.jgit.treewalk.WorkingTreeIterator.getIgnoreNode(WorkingTreeIterator.java:625)
at 
org.eclipse.jgit.treewalk.WorkingTreeIterator.isEntryIgnored(WorkingTreeIterator.java:593)
at 
org.eclipse.jgit.treewalk.WorkingTreeIterator.isEntryIgnored(WorkingTreeIterator.java:576)
at 
org.eclipse.jgit.treewalk.WorkingTreeIterator.isEntryIgnored(WorkingTreeIterator.java:563)
at 
org.netbeans.libs.git.jgit.commands.StatusCommand.run(StatusCommand.java:182)
at 
org.netbeans.libs.git.jgit.commands.GitCommand$1.run(GitCommand.java:57)
at 
org.netbeans.libs.git.jgit.commands.GitCommand$1.run(GitCommand.java:54)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at 
org.netbeans.libs.git.jgit.commands.GitCommand.execute(GitCommand.java:54)
at org.netbeans.libs.git.GitClient.getStatus(GitClient.java:737)
at org.netbeans.modules.git.client.GitClient$26.call(GitClient.java:477)
at org.netbeans.modules.git.client.GitClient$26.call(GitClient.java:473)
at 
org.netbeans.modules.git.client.GitClient$CommandInvoker$1$1.call(GitClient.java:933)
at 
org.netbeans.modules.git.client.GitClient$CommandInvoker$1.call(GitClient.java:956)
at 
org.netbeans.modules.git.client.GitClient$CommandInvoker.runMethodIntern(GitClient.java:968)
at 
org.netbeans.modules.git.client.GitClient$CommandInvoker.runMethod(GitClient.java:897)
at 
org.netbeans.modules.git.client.GitClient$CommandInvoker.access$300(GitClient.java:869)
at 
org.netbeans.modules.git.client.GitClient.getStatus(GitClient.java:473)
at 
org.netbeans.modules.git.client.GitClient.getStatus(GitClient.java:469)
at 
org.netbeans.modules.git.FileStatusCache.refreshAllRoots(FileStatusCache.java:210)
at 
org.netbeans.modules.git.FileStatusCache.refreshAllRoots(FileStatusCache.java:170)
at 
org.netbeans.modules.git.FilesystemInterceptor$RefreshTask.run(FilesystemInterceptor.java:669)
Caused: org.openide.util.RequestProcessor$SlowItem: task failed due to
at 
org.openide.util.RequestProcessor$Task.schedule(RequestProcessor.java:1459)
at 
org.netbeans.modules.git.FilesystemInterceptor.reScheduleRefresh(FilesystemInterceptor.java:755)
at 
org.netbeans.modules.git.FilesystemInterceptor.access$3300(FilesystemInterceptor.java:73)
at 
org.netbeans.modules.git.FilesystemInterceptor$GitFolderEventsHandler.initializeFiles(FilesystemInterceptor.java:1023)
at 
org.netbeans.modules.git.FilesystemInterceptor$GitFolderEventsHandler.access$2500(FilesystemInterceptor.java:842)
at 
org.netbeans.modules.git.FilesystemInterceptor$GitFolderEventsHandler$1.run(FilesystemInterceptor.java:854)
at 
org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
at 
org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
[catch] at 
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Assigned] (NETBEANS-867) Refactoring popup does not close

2018-06-25 Thread chopin xiao (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chopin xiao reassigned NETBEANS-867:


Assignee: (was: chopin xiao)

> Refactoring popup does not close
> 
>
> Key: NETBEANS-867
> URL: https://issues.apache.org/jira/browse/NETBEANS-867
> Project: NetBeans
>  Issue Type: Bug
>  Components: php - Refactoring
>Affects Versions: 8.2
> Environment: Product Version: NetBeans IDE 8.2 (Build 201609300101)
> Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2
> Java: 1.8.0_171; OpenJDK 64-Bit Server VM 25.171-b10
> Runtime: OpenJDK Runtime Environment 1.8.0_171-b10
> System: Linux version 4.16.11-200.fc27.x86_64 running on amd64; UTF-8; en_US 
> (nb)
> User directory: /home/chopin/.netbeans/8.2
> Cache directory: /home/chopin/.cache/netbeans/8.2
>Reporter: chopin xiao
>Priority: Major
> Attachments: 2018-05-27 11-30-21屏幕截图.png
>
>
> when refactor-rename php code many times, the refactoring popup box will does 
> not close
>  This issue reproduce only while refactor after many times, may be after 
> refactor three times reproduce
>  like below unsolve bug:
>  [https://netbeans.org/bugzilla/show_bug.cgi?id=252972]
>  [https://netbeans.org/bugzilla/show_bug.cgi?id=258261]
>  [https://netbeans.org/bugzilla/show_bug.cgi?id=268493]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Assigned] (NETBEANS-867) Refactoring popup does not close

2018-06-25 Thread chopin xiao (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chopin xiao reassigned NETBEANS-867:


Assignee: chopin xiao

> Refactoring popup does not close
> 
>
> Key: NETBEANS-867
> URL: https://issues.apache.org/jira/browse/NETBEANS-867
> Project: NetBeans
>  Issue Type: Bug
>  Components: php - Refactoring
>Affects Versions: 8.2
> Environment: Product Version: NetBeans IDE 8.2 (Build 201609300101)
> Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2
> Java: 1.8.0_171; OpenJDK 64-Bit Server VM 25.171-b10
> Runtime: OpenJDK Runtime Environment 1.8.0_171-b10
> System: Linux version 4.16.11-200.fc27.x86_64 running on amd64; UTF-8; en_US 
> (nb)
> User directory: /home/chopin/.netbeans/8.2
> Cache directory: /home/chopin/.cache/netbeans/8.2
>Reporter: chopin xiao
>Assignee: chopin xiao
>Priority: Major
> Attachments: 2018-05-27 11-30-21屏幕截图.png
>
>
> when refactor-rename php code many times, the refactoring popup box will does 
> not close
>  This issue reproduce only while refactor after many times, may be after 
> refactor three times reproduce
>  like below unsolve bug:
>  [https://netbeans.org/bugzilla/show_bug.cgi?id=252972]
>  [https://netbeans.org/bugzilla/show_bug.cgi?id=258261]
>  [https://netbeans.org/bugzilla/show_bug.cgi?id=268493]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Created] (NETBEANS-994) NetBeans deletes remote files, when local project-file-location gets offline

2018-06-25 Thread Heli Ammann (JIRA)
Heli Ammann created NETBEANS-994:


 Summary: NetBeans deletes remote files, when local 
project-file-location gets offline
 Key: NETBEANS-994
 URL: https://issues.apache.org/jira/browse/NETBEANS-994
 Project: NetBeans
  Issue Type: Bug
  Components: apisupport - Project, projects - Generic Infrastructure
Affects Versions: 8.2
Reporter: Heli Ammann


Product Version = NetBeans IDE 8.2 (Build 201705191307)
Operating System = Windows 7 version 6.1 running on amd64
Java; VM; Vendor = 1.8.0_101
Runtime = Java HotSpot(TM) 64-Bit Server VM 25.101-b13

STEPS:
  * Open project-files from a local fileserver
  * Configure Remote Connection with "Upload Files = On Save"
  * Disconnect connection to local fileserver

ACTUAL:
  NetBeans begins to delete all files on the remote connection -> website is 
destroyed

EXPECTED:
  NetBeans checks if project-file-location is available, bevore deleting remote 
files



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-980) Home/end/up/down do not work properly when word wrapping is enabled

2018-06-25 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated NETBEANS-980:

Labels: pull-request-available  (was: )

> Home/end/up/down do not work properly when word wrapping is enabled
> ---
>
> Key: NETBEANS-980
> URL: https://issues.apache.org/jira/browse/NETBEANS-980
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Other, editor - Painting  Printing
>Affects Versions: 9.0
>Reporter: Eirik Bakke
>Priority: Major
>  Labels: pull-request-available
>
> Caret movements via Home/End and arrow Up/Down keys do not work properly when 
> text wrap (especially in "after words" mode) is enabled in the NetBeans 
> editor.
> Specific bugs:
> 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the 
> beginning of the paragraph rather than to the beginning of the current wrap 
> line (physical line).
> 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the 
> beginning of the next wrap line instead of to the end of the current wrap 
> line.
> 3) Pressing Up has no effect if the preceding wrap line ended before the 
> caret's current X position.
> 4) Pressing Down will move the caret down _two_ lines if the following wrap 
> line ended before the caret's current X position (and assuming the wrap line 
> two lines down is long enough).
> 5) Left-clicking the mouse to the right of the end of a wrap line puts the 
> caret on the beginning of the next wrap line rather than at the end of the 
> current (clicked) wrap line.
> The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit 
> (UpAction/DownAction/BeginLineAction/EndLineAction).
> Bug number 1 above, for the Home action (BeginLineAction), is easy to fix and 
> is unrelated to the others. (Don't allow Utilities.getRowFirstNonWhite to 
> move the caret before lineStartPos.)
> Bugs 2-5 above all relate to what caret position is mapped to the "infinite" 
> horizontal space that follows each wrap line. With NetBeans' current 
> behavior, this space corresponds to a caret position directly following the 
> last character of a wrap line. This caret position, however, is physically 
> mapped (and painted) on the beginning of the following wrap line, which 
> confuses the logic for the End, Up, and Down actions. I suspect that if bug 5 
> is fixed, then bugs 2-4 might "fix themselves" as well.
> For bug 5, I think the best solution when clicking the space beyond the end 
> of a wrap line would be to move the caret to right _before_ the last 
> character on the wrap line. This character is usually a space (in word wrap 
> mode), though it could also be a hyphen or such if a more advanced word 
> wrapping algorithm is used (proposed in the pull request for NETBEANS-977). 
> The resulting behavior would be similar to that of a default JTextArea, or 
> jEdit (though these never break words on anything else than a space). Another 
> solution would be to do like the TextEdit app on MacOS, where the cursor is 
> placed _after_ the last character on the wrap line, like NetBeans currently 
> does, but with a backwards bias such that the cursor is painted on the end of 
> the current wrap line instead of on the beginning of the next wrap line. The 
> latter is probably harder to implement, and is not really necessary.
> To test the above bugs:
> 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
> set "Line Wrap" to "After words". Click OK.
> 2) Create a new plain text file and paste in the paragraph "SHORTWORD 
> LONGWORD SHORTWORD LUUUNGWORD".
> 3) Resize the editor window so that the paragraph gets split into four wrap 
> lines (one word on each wrap line--i.e. make the editor a little wider than 
> the long word).
> 4) For each bugs 1-4 listed above, position the caret right after 
> "...ONG", then press the relevant key to test.
> 5) To test bug 5 above, click the mouse to the right of the first, second, or 
> third wrap line.
> Tested in NetBeans 9.0 rc1.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Commented] (NETBEANS-956) Position / Color of SplashScreen ProgressBar/Text is broken with new branding

2018-06-25 Thread Sven Reimers (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522807#comment-16522807
 ] 

Sven Reimers commented on NETBEANS-956:
---

PR for master https://github.com/apache/incubator-netbeans/pull/602

> Position / Color of SplashScreen ProgressBar/Text is broken with new branding
> -
>
> Key: NETBEANS-956
> URL: https://issues.apache.org/jira/browse/NETBEANS-956
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - UI
>Affects Versions: 9.0
>Reporter: Sven Reimers
>Assignee: Sven Reimers
>Priority: Major
>  Labels: branding, pull-request-available
> Attachments: NewProgressBarAndTextBranding.png, 
> fix-progress-bar-and-text.diff
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> With change of the splash screen the other bits and pieces do not fit that 
> well anymore.
> Attached is a diff and a screenshot of a probable solution.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Commented] (NETBEANS-798) Netbeans crashes after closing snipping tools

2018-06-25 Thread Thierry Danard (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522770#comment-16522770
 ] 

Thierry Danard commented on NETBEANS-798:
-

I am not the original poster, others might have a different use case. For my 
particular example, it's all lighweight/swing components. I agree this is not a 
critical issue from a NetBeans release point of view.

> Netbeans crashes after closing snipping tools
> -
>
> Key: NETBEANS-798
> URL: https://issues.apache.org/jira/browse/NETBEANS-798
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - JDK Problems
>Affects Versions: 8.2
>Reporter: Eduard Fekete
>Priority: Critical
>  Labels: Windows10
> Attachments: Snipping tool issue.mov, b0.PNG, hs_err_pid10608.log, 
> hs_err_pid7492.log, hs_err_pid7920.log
>
>
> I opened the dialog to create a new project because I wanted to take a 
> screenshot of it for a bug report, by using snipping tools. Ironically I 
> found another bug, after taking the screenshot and closing snipping tools, 
> NetBeans crashed. I was able to reproduce this many times.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Commented] (NETBEANS-931) OutOfMemory after a night of stand-by

2018-06-25 Thread Laszlo Kishalmi (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522753#comment-16522753
 ] 

Laszlo Kishalmi commented on NETBEANS-931:
--

Could we get a Heapdump before you stop using the IDE and another one next 
morning (or when the crash happens.)?

> OutOfMemory after a night of stand-by
> -
>
> Key: NETBEANS-931
> URL: https://issues.apache.org/jira/browse/NETBEANS-931
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 9.0
>Reporter: Luca Mambretti
>Priority: Critical
> Attachments: messages.log, uigestures.xml
>
>
> After a full day of work I left the system running (it had manifested the 
> errors described in NETBEANS-901).
>  
> The day after it was out of commission with OOM.
>  
> attached IDE logs and gestures, I also have the heap dump but it's 1.5 gigs 
> so I doubt I'll be able to attach it (sent it thru a WeTransfer link for now)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Commented] (NETBEANS-931) OutOfMemory after a night of stand-by

2018-06-25 Thread Laszlo Kishalmi (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522739#comment-16522739
 ] 

Laszlo Kishalmi commented on NETBEANS-931:
--

Got it. It seems somewhere we have a serious leak on WeakListener. The heapdump 
says we have more than 10 million of 
org.openide.util.WeakListenerImpl$ListenerReference eating up 640 Mb of heap.

Could you provide the IDE build and git commit number as well? It's in the Help 
-> About dialog.

> OutOfMemory after a night of stand-by
> -
>
> Key: NETBEANS-931
> URL: https://issues.apache.org/jira/browse/NETBEANS-931
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 9.0
>Reporter: Luca Mambretti
>Priority: Critical
> Attachments: messages.log, uigestures.xml
>
>
> After a full day of work I left the system running (it had manifested the 
> errors described in NETBEANS-901).
>  
> The day after it was out of commission with OOM.
>  
> attached IDE logs and gestures, I also have the heap dump but it's 1.5 gigs 
> so I doubt I'll be able to attach it (sent it thru a WeTransfer link for now)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Commented] (NETBEANS-798) Netbeans crashes after closing snipping tools

2018-06-25 Thread Laszlo Kishalmi (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522735#comment-16522735
 ] 

Laszlo Kishalmi commented on NETBEANS-798:
--

As I see it is a desktop application built on NetBeans Platform. Could it 
happen that you might use heavyweight (java.awt) or custom components in your 
application?

I'm going to close this issue, as if the message log is empty regarding the 
crash then it is outside of our reach. Try to check it under Linux or Mac if 
windows fails.

I only could wish you guys the bests, but we are sorry this is really out of 
our reach.

> Netbeans crashes after closing snipping tools
> -
>
> Key: NETBEANS-798
> URL: https://issues.apache.org/jira/browse/NETBEANS-798
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - JDK Problems
>Affects Versions: 8.2
>Reporter: Eduard Fekete
>Priority: Critical
>  Labels: Windows10
> Attachments: Snipping tool issue.mov, b0.PNG, hs_err_pid10608.log, 
> hs_err_pid7492.log, hs_err_pid7920.log
>
>
> I opened the dialog to create a new project because I wanted to take a 
> screenshot of it for a bug report, by using snipping tools. Ironically I 
> found another bug, after taking the screenshot and closing snipping tools, 
> NetBeans crashed. I was able to reproduce this many times.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Closed] (NETBEANS-798) Netbeans crashes after closing snipping tools

2018-06-25 Thread Laszlo Kishalmi (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Laszlo Kishalmi closed NETBEANS-798.

Resolution: Information Provided

> Netbeans crashes after closing snipping tools
> -
>
> Key: NETBEANS-798
> URL: https://issues.apache.org/jira/browse/NETBEANS-798
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - JDK Problems
>Affects Versions: 8.2
>Reporter: Eduard Fekete
>Priority: Critical
>  Labels: Windows10
> Attachments: Snipping tool issue.mov, b0.PNG, hs_err_pid10608.log, 
> hs_err_pid7492.log, hs_err_pid7920.log
>
>
> I opened the dialog to create a new project because I wanted to take a 
> screenshot of it for a bug report, by using snipping tools. Ironically I 
> found another bug, after taking the screenshot and closing snipping tools, 
> NetBeans crashed. I was able to reproduce this many times.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-798) Netbeans crashes after closing snipping tools

2018-06-25 Thread Laszlo Kishalmi (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Laszlo Kishalmi updated NETBEANS-798:
-
Component/s: platform - JDK Problems

> Netbeans crashes after closing snipping tools
> -
>
> Key: NETBEANS-798
> URL: https://issues.apache.org/jira/browse/NETBEANS-798
> Project: NetBeans
>  Issue Type: Bug
>  Components: platform - JDK Problems
>Affects Versions: 8.2
>Reporter: Eduard Fekete
>Priority: Critical
>  Labels: Windows10
> Attachments: Snipping tool issue.mov, b0.PNG, hs_err_pid10608.log, 
> hs_err_pid7492.log, hs_err_pid7920.log
>
>
> I opened the dialog to create a new project because I wanted to take a 
> screenshot of it for a bug report, by using snipping tools. Ironically I 
> found another bug, after taking the screenshot and closing snipping tools, 
> NetBeans crashed. I was able to reproduce this many times.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Commented] (NETBEANS-781) java.lang.ClassFormatError: Invalid Constant Pool entry Type 19 in build-impl.xml

2018-06-25 Thread Emilian Bold (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522576#comment-16522576
 ] 

Emilian Bold commented on NETBEANS-781:
---

Created review for patch https://reviews.apache.org/r/67721/

> java.lang.ClassFormatError: Invalid Constant Pool entry Type 19  in 
> build-impl.xml
> --
>
> Key: NETBEANS-781
> URL: https://issues.apache.org/jira/browse/NETBEANS-781
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Ant Project
>Affects Versions: 9.0
> Environment: Product Version: Apache NetBeans IDE Dev (Build 
> incubator-netbeans-release-285-on-20180502)
> Java: 10.0.1; Java HotSpot(TM) 64-Bit Server VM 10.0.1+10
> Runtime: Java(TM) SE Runtime Environment 10.0.1+10
> System: Linux version 4.15.0-20-generic running on amd64; UTF-8; en_US (nb)
>Reporter: Simon IJskes
>Assignee: Emilian Bold
>Priority: Major
>  Labels: pull-request-available
> Attachments: JavaApplication10.zip
>
>  Time Spent: 4h 2m
>  Remaining Estimate: 0h
>
> When i build a project (target jar) with do.depend=true (in 
> project.properties or private.properties) for a second time after clean, the 
> following is thrown:
> java.lang.ClassFormatError: Invalid Constant Pool entry Type 19 
>  at 
> org.apache.tools.ant.taskdefs.optional.depend.constantpool.ConstantPoolEntry.readEntry(ConstantPoolEntry.java:180)
> This is in the depend macro:
>      excludes="${excludes}" includes="${includes}" srcdir="@\{srcdir}"> 
>       
>       
>       
>      
>  
> project properties:
> javac.source=10 
>  javac.target=10 
>  platform.active=JDK_10
> The exception is thrown direct after opening build/classes/module-info.class



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Commented] (NETBEANS-781) java.lang.ClassFormatError: Invalid Constant Pool entry Type 19 in build-impl.xml

2018-06-25 Thread Emilian Bold (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522522#comment-16522522
 ] 

Emilian Bold commented on NETBEANS-781:
---

OK, I have 
https://hg.netbeans.org/binaries/D6330851B59C33A3A8D98C86FF438F23DD3B4267-ant-misc-1.10.4.zip
 let me make a PR.

> java.lang.ClassFormatError: Invalid Constant Pool entry Type 19  in 
> build-impl.xml
> --
>
> Key: NETBEANS-781
> URL: https://issues.apache.org/jira/browse/NETBEANS-781
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Ant Project
>Affects Versions: 9.0
> Environment: Product Version: Apache NetBeans IDE Dev (Build 
> incubator-netbeans-release-285-on-20180502)
> Java: 10.0.1; Java HotSpot(TM) 64-Bit Server VM 10.0.1+10
> Runtime: Java(TM) SE Runtime Environment 10.0.1+10
> System: Linux version 4.15.0-20-generic running on amd64; UTF-8; en_US (nb)
>Reporter: Simon IJskes
>Assignee: Emilian Bold
>Priority: Major
>  Labels: pull-request-available
> Attachments: JavaApplication10.zip
>
>  Time Spent: 4h 2m
>  Remaining Estimate: 0h
>
> When i build a project (target jar) with do.depend=true (in 
> project.properties or private.properties) for a second time after clean, the 
> following is thrown:
> java.lang.ClassFormatError: Invalid Constant Pool entry Type 19 
>  at 
> org.apache.tools.ant.taskdefs.optional.depend.constantpool.ConstantPoolEntry.readEntry(ConstantPoolEntry.java:180)
> This is in the depend macro:
>      excludes="${excludes}" includes="${includes}" srcdir="@\{srcdir}"> 
>       
>       
>       
>      
>  
> project properties:
> javac.source=10 
>  javac.target=10 
>  platform.active=JDK_10
> The exception is thrown direct after opening build/classes/module-info.class



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-990) Creating a new NetBeans Project from template has the old branding.

2018-06-25 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated NETBEANS-990:

Labels: branding pull-request-available  (was: branding)

> Creating a new NetBeans Project from template has the old branding.
> ---
>
> Key: NETBEANS-990
> URL: https://issues.apache.org/jira/browse/NETBEANS-990
> Project: NetBeans
>  Issue Type: Bug
>  Components: apisupport - Project
>Affects Versions: 9.0
>Reporter: Laszlo Kishalmi
>Priority: Major
>  Labels: branding, pull-request-available
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Commented] (NETBEANS-798) Netbeans crashes after closing snipping tools

2018-06-25 Thread Eduardo Quintanilla (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522456#comment-16522456
 ] 

Eduardo Quintanilla commented on NETBEANS-798:
--

Could you share the contents of IDE Log (View => IDE Log)?
%APPDATA%\Roaming\NetBeans\8.2\var\log\messages.log

> Netbeans crashes after closing snipping tools
> -
>
> Key: NETBEANS-798
> URL: https://issues.apache.org/jira/browse/NETBEANS-798
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 8.2
>Reporter: Eduard Fekete
>Priority: Critical
>  Labels: Windows10
> Attachments: b0.PNG, hs_err_pid10608.log, hs_err_pid7492.log, 
> hs_err_pid7920.log
>
>
> I opened the dialog to create a new project because I wanted to take a 
> screenshot of it for a bug report, by using snipping tools. Ironically I 
> found another bug, after taking the screenshot and closing snipping tools, 
> NetBeans crashed. I was able to reproduce this many times.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Commented] (NETBEANS-798) Netbeans crashes after closing snipping tools

2018-06-25 Thread Thierry Danard (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522452#comment-16522452
 ] 

Thierry Danard commented on NETBEANS-798:
-

hs_err_pid7920.log is the log with Java 10.

So far, we could only reproduce this issue with the snipping tool, but we'll 
try with other tools.

> Netbeans crashes after closing snipping tools
> -
>
> Key: NETBEANS-798
> URL: https://issues.apache.org/jira/browse/NETBEANS-798
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 8.2
>Reporter: Eduard Fekete
>Priority: Critical
>  Labels: Windows10
> Attachments: b0.PNG, hs_err_pid10608.log, hs_err_pid7492.log, 
> hs_err_pid7920.log
>
>
> I opened the dialog to create a new project because I wanted to take a 
> screenshot of it for a bug report, by using snipping tools. Ironically I 
> found another bug, after taking the screenshot and closing snipping tools, 
> NetBeans crashed. I was able to reproduce this many times.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-798) Netbeans crashes after closing snipping tools

2018-06-25 Thread Thierry Danard (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thierry Danard updated NETBEANS-798:

Attachment: hs_err_pid7920.log

> Netbeans crashes after closing snipping tools
> -
>
> Key: NETBEANS-798
> URL: https://issues.apache.org/jira/browse/NETBEANS-798
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 8.2
>Reporter: Eduard Fekete
>Priority: Critical
>  Labels: Windows10
> Attachments: b0.PNG, hs_err_pid10608.log, hs_err_pid7492.log, 
> hs_err_pid7920.log
>
>
> I opened the dialog to create a new project because I wanted to take a 
> screenshot of it for a bug report, by using snipping tools. Ironically I 
> found another bug, after taking the screenshot and closing snipping tools, 
> NetBeans crashed. I was able to reproduce this many times.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-798) Netbeans crashes after closing snipping tools

2018-06-25 Thread Thierry Danard (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thierry Danard updated NETBEANS-798:

Attachment: hs_err_pid10608.log

> Netbeans crashes after closing snipping tools
> -
>
> Key: NETBEANS-798
> URL: https://issues.apache.org/jira/browse/NETBEANS-798
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 8.2
>Reporter: Eduard Fekete
>Priority: Critical
>  Labels: Windows10
> Attachments: b0.PNG, hs_err_pid10608.log, hs_err_pid7492.log
>
>
> I opened the dialog to create a new project because I wanted to take a 
> screenshot of it for a bug report, by using snipping tools. Ironically I 
> found another bug, after taking the screenshot and closing snipping tools, 
> NetBeans crashed. I was able to reproduce this many times.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Commented] (NETBEANS-798) Netbeans crashes after closing snipping tools

2018-06-25 Thread Geertjan Wielenga (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522409#comment-16522409
 ] 

Geertjan Wielenga commented on NETBEANS-798:


The question is also whether the snipping tools are the only tools you can use 
for what it is you're doing and whether using some other tool that does the 
same thing causes the same problem.

> Netbeans crashes after closing snipping tools
> -
>
> Key: NETBEANS-798
> URL: https://issues.apache.org/jira/browse/NETBEANS-798
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 8.2
>Reporter: Eduard Fekete
>Priority: Critical
>  Labels: Windows10
> Attachments: b0.PNG, hs_err_pid7492.log
>
>
> I opened the dialog to create a new project because I wanted to take a 
> screenshot of it for a bug report, by using snipping tools. Ironically I 
> found another bug, after taking the screenshot and closing snipping tools, 
> NetBeans crashed. I was able to reproduce this many times.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Commented] (NETBEANS-798) Netbeans crashes after closing snipping tools

2018-06-25 Thread Thierry Danard (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522405#comment-16522405
 ] 

Thierry Danard commented on NETBEANS-798:
-

I have attached  the crash logs on Java 8.

I am working on getting the same error logs on Java 9 and 10

> Netbeans crashes after closing snipping tools
> -
>
> Key: NETBEANS-798
> URL: https://issues.apache.org/jira/browse/NETBEANS-798
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 8.2
>Reporter: Eduard Fekete
>Priority: Critical
>  Labels: Windows10
> Attachments: b0.PNG, hs_err_pid7492.log
>
>
> I opened the dialog to create a new project because I wanted to take a 
> screenshot of it for a bug report, by using snipping tools. Ironically I 
> found another bug, after taking the screenshot and closing snipping tools, 
> NetBeans crashed. I was able to reproduce this many times.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-798) Netbeans crashes after closing snipping tools

2018-06-25 Thread Thierry Danard (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thierry Danard updated NETBEANS-798:

Attachment: hs_err_pid7492.log

> Netbeans crashes after closing snipping tools
> -
>
> Key: NETBEANS-798
> URL: https://issues.apache.org/jira/browse/NETBEANS-798
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 8.2
>Reporter: Eduard Fekete
>Priority: Critical
>  Labels: Windows10
> Attachments: b0.PNG, hs_err_pid7492.log
>
>
> I opened the dialog to create a new project because I wanted to take a 
> screenshot of it for a bug report, by using snipping tools. Ironically I 
> found another bug, after taking the screenshot and closing snipping tools, 
> NetBeans crashed. I was able to reproduce this many times.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Created] (NETBEANS-993) Template Wizard ignores folder selection sometimes

2018-06-25 Thread Svatopluk Dedic (JIRA)
Svatopluk Dedic created NETBEANS-993:


 Summary: Template Wizard ignores folder selection sometimes
 Key: NETBEANS-993
 URL: https://issues.apache.org/jira/browse/NETBEANS-993
 Project: NetBeans
  Issue Type: Bug
  Components: platform - Data Systems
Reporter: Svatopluk Dedic
Assignee: Svatopluk Dedic


The template wizard allows to select a folder where the template is 
instantiated. If the user selects the target folder using the file list (i.e. 
doubleclicks the folder name), everything seems to be OK - the custom 
PropertyEditor calls setValue --> setTargetFolder on the wizard panel.

But I don't see such a call if the user selects a (parent) folder using the 
combobox above the file list. 

Note that if the user first selects a parent from the dropdown, then picks some 
child (i.e. sibling of the original), the template wizard will use the 
appropriate value.

To reproduce: invoke new from template from some folder. Select some of the 
parents from the drop down. check that "Look in" edit box indeed changed the 
folder's name. Press Finish. The file will be created in the folder originally 
selected, not the current one.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Created] (NETBEANS-992) Exception when singlestep debugging

2018-06-25 Thread Jacco van Weert (JIRA)
Jacco van Weert created NETBEANS-992:


 Summary: Exception when singlestep debugging
 Key: NETBEANS-992
 URL: https://issues.apache.org/jira/browse/NETBEANS-992
 Project: NetBeans
  Issue Type: Bug
Reporter: Jacco van Weert


java.lang.AssertionError: Debugger lock taken in AWT Event Queue!
 at 
org.netbeans.modules.debugger.jpda.JPDADebuggerImpl$DebuggerReentrantReadWriteLock$DebuggerReadLock.lock(JPDADebuggerImpl.java:2675)
 at 
org.netbeans.modules.debugger.jpda.models.JPDAThreadImpl$ThreadReentrantReadWriteLock$ThreadWriteLock.lock(JPDAThreadImpl.java:2555)
 at 
org.netbeans.modules.debugger.jpda.JPDADebuggerImpl.invokeMethod(JPDADebuggerImpl.java:1066)
 at 
org.netbeans.modules.debugger.jpda.JPDADebuggerImpl.invokeMethod(JPDADebuggerImpl.java:1008)
 at 
org.netbeans.modules.debugger.jpda.models.AbstractObjectVariable.getToStringValue(AbstractObjectVariable.java:496)
 at 
org.netbeans.modules.debugger.jpda.models.AbstractObjectVariable.getToStringValue(AbstractObjectVariable.java:460)
 at 
org.netbeans.modules.debugger.jpda.models.AbstractObjectVariable.getToStringValue(AbstractObjectVariable.java:424)
 at 
org.netbeans.modules.debugger.jpda.ui.models.VariablesTableModel.getValueAt(VariablesTableModel.java:108)
 at 
org.netbeans.spi.viewmodel.Models$DelegatingTableModel.getValueAt(Models.java:2249)
 at 
org.netbeans.modules.debugger.jpda.ui.models.NumericDisplayFilter.getValueAt(NumericDisplayFilter.java:112)
 at 
org.netbeans.spi.viewmodel.Models$CompoundTableModel.getValueAt(Models.java:1439)
 at 
org.netbeans.modules.debugger.jpda.ui.models.VariablesTreeModelFilter.getValueAt(VariablesTreeModelFilter.java:530)
 at 
org.netbeans.spi.viewmodel.Models$CompoundTableModel.getValueAt(Models.java:1439)
 at 
org.netbeans.modules.debugger.jpda.ui.models.PendingActionsFilter.getValueAt(PendingActionsFilter.java:108)
 at 
org.netbeans.spi.viewmodel.Models$CompoundTableModel.getValueAt(Models.java:1439)
 at 
org.netbeans.spi.viewmodel.Models$CompoundTableModel.getValueAt(Models.java:1441)
 at 
org.netbeans.spi.viewmodel.Models$CompoundTableModel.getValueAt(Models.java:1441)
 at org.netbeans.spi.viewmodel.Models$CompoundModel.getValueAt(Models.java:4566)
 at 
org.netbeans.modules.viewmodel.TreeModelNode$MyProperty.updateShortDescription(TreeModelNode.java:2102)
 at 
org.netbeans.modules.viewmodel.TreeModelNode$MyProperty.getShortDescription(TreeModelNode.java:2084)
 at 
org.openide.explorer.view.SheetCell.getTableCellRendererComponent(SheetCell.java:276)
 at 
org.openide.explorer.view.SheetCell$OutlineSheetCell.getTableCellRendererComponent(SheetCell.java:737)
 at 
org.netbeans.modules.viewmodel.DelegatingCellRenderer.getTableCellRendererComponent(DelegatingCellRenderer.java:66)
 at javax.swing.JTable.prepareRenderer(JTable.java:5723)
 at org.netbeans.swing.outline.Outline.getToolTipText(Outline.java:393)
 at 
javax.swing.ToolTipManager$insideTimerAction.actionPerformed(ToolTipManager.java:663)
 at javax.swing.Timer.fireActionPerformed(Timer.java:313)
 at javax.swing.Timer$DoPostEvent.run(Timer.java:245)
 at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
 at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
 at java.awt.EventQueue.access$500(EventQueue.java:97)
 at java.awt.EventQueue$3.run(EventQueue.java:709)
 at java.awt.EventQueue$3.run(EventQueue.java:703)
 at java.security.AccessController.doPrivileged(Native Method)
 at 
java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
 at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
 at 
org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:136)
[catch] at 
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
 at 
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
 at 
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
 at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
 at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
 at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Commented] (NETBEANS-781) java.lang.ClassFormatError: Invalid Constant Pool entry Type 19 in build-impl.xml

2018-06-25 Thread Simon IJskes (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522187#comment-16522187
 ] 

Simon IJskes commented on NETBEANS-781:
---

i think it was already maven based.

> java.lang.ClassFormatError: Invalid Constant Pool entry Type 19  in 
> build-impl.xml
> --
>
> Key: NETBEANS-781
> URL: https://issues.apache.org/jira/browse/NETBEANS-781
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Ant Project
>Affects Versions: 9.0
> Environment: Product Version: Apache NetBeans IDE Dev (Build 
> incubator-netbeans-release-285-on-20180502)
> Java: 10.0.1; Java HotSpot(TM) 64-Bit Server VM 10.0.1+10
> Runtime: Java(TM) SE Runtime Environment 10.0.1+10
> System: Linux version 4.15.0-20-generic running on amd64; UTF-8; en_US (nb)
>Reporter: Simon IJskes
>Assignee: Emilian Bold
>Priority: Major
>  Labels: pull-request-available
> Attachments: JavaApplication10.zip
>
>  Time Spent: 4h 2m
>  Remaining Estimate: 0h
>
> When i build a project (target jar) with do.depend=true (in 
> project.properties or private.properties) for a second time after clean, the 
> following is thrown:
> java.lang.ClassFormatError: Invalid Constant Pool entry Type 19 
>  at 
> org.apache.tools.ant.taskdefs.optional.depend.constantpool.ConstantPoolEntry.readEntry(ConstantPoolEntry.java:180)
> This is in the depend macro:
>      excludes="${excludes}" includes="${includes}" srcdir="@\{srcdir}"> 
>       
>       
>       
>      
>  
> project properties:
> javac.source=10 
>  javac.target=10 
>  platform.active=JDK_10
> The exception is thrown direct after opening build/classes/module-info.class



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-991) requestAttention() not working on macOS Sierra

2018-06-25 Thread Ionut Enescu (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ionut Enescu updated NETBEANS-991:
--
Description: 
Calling requestAttention() on a TopComponent works as expected on Win7 x64 and 
Ubuntu 16.04, but not on macOS Sierra (10.12.6). There's no error message or 
any indication that something went wrong in the execution.

 

  was:
Calling requestAttention() on a TopComponent works as expected on Win7 x64 and 
Ubuntu 16.04, but not on macOS Sierra (10.12.6).

 


> requestAttention() not working on macOS Sierra
> --
>
> Key: NETBEANS-991
> URL: https://issues.apache.org/jira/browse/NETBEANS-991
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - UI
>Affects Versions: 8.2
> Environment: macOS Sierra (10.12.6).
> JDK 1.8u121
> Netbeans 8.2
>Reporter: Ionut Enescu
>Priority: Major
>
> Calling requestAttention() on a TopComponent works as expected on Win7 x64 
> and Ubuntu 16.04, but not on macOS Sierra (10.12.6). There's no error message 
> or any indication that something went wrong in the execution.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Created] (NETBEANS-991) requestAttention() not working on macOS Sierra

2018-06-25 Thread Ionut Enescu (JIRA)
Ionut Enescu created NETBEANS-991:
-

 Summary: requestAttention() not working on macOS Sierra
 Key: NETBEANS-991
 URL: https://issues.apache.org/jira/browse/NETBEANS-991
 Project: NetBeans
  Issue Type: Bug
  Components: ide - UI
Affects Versions: 8.2
 Environment: macOS Sierra (10.12.6).
JDK 1.8u121
Netbeans 8.2
Reporter: Ionut Enescu


Calling requestAttention() on a TopComponent works as expected on Win7 x64 and 
Ubuntu 16.04, but not on macOS Sierra (10.12.6).

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Commented] (NETBEANS-781) java.lang.ClassFormatError: Invalid Constant Pool entry Type 19 in build-impl.xml

2018-06-25 Thread Emilian Bold (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522179#comment-16522179
 ] 

Emilian Bold commented on NETBEANS-781:
---

OK, let me see how to do this step: "updating the ant-misc zip and uploading it 
to hg.netbeans.org/binaries".

I see the Ant guys were busy reformatting shell scripts so the files in 
ant-misc need updating. I suspect the existing ant-misc might be sufficient but 
I want to keep these in sync.

> java.lang.ClassFormatError: Invalid Constant Pool entry Type 19  in 
> build-impl.xml
> --
>
> Key: NETBEANS-781
> URL: https://issues.apache.org/jira/browse/NETBEANS-781
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Ant Project
>Affects Versions: 9.0
> Environment: Product Version: Apache NetBeans IDE Dev (Build 
> incubator-netbeans-release-285-on-20180502)
> Java: 10.0.1; Java HotSpot(TM) 64-Bit Server VM 10.0.1+10
> Runtime: Java(TM) SE Runtime Environment 10.0.1+10
> System: Linux version 4.15.0-20-generic running on amd64; UTF-8; en_US (nb)
>Reporter: Simon IJskes
>Assignee: Emilian Bold
>Priority: Major
>  Labels: pull-request-available
> Attachments: JavaApplication10.zip
>
>  Time Spent: 4h 2m
>  Remaining Estimate: 0h
>
> When i build a project (target jar) with do.depend=true (in 
> project.properties or private.properties) for a second time after clean, the 
> following is thrown:
> java.lang.ClassFormatError: Invalid Constant Pool entry Type 19 
>  at 
> org.apache.tools.ant.taskdefs.optional.depend.constantpool.ConstantPoolEntry.readEntry(ConstantPoolEntry.java:180)
> This is in the depend macro:
>      excludes="${excludes}" includes="${includes}" srcdir="@\{srcdir}"> 
>       
>       
>       
>      
>  
> project properties:
> javac.source=10 
>  javac.target=10 
>  platform.active=JDK_10
> The exception is thrown direct after opening build/classes/module-info.class



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-862) Autocomplete for var keyword not supported in Lambda parameter

2018-06-25 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated NETBEANS-862:

Labels: JDK11-VarInLambda pull-request-available  (was: JDK11-VarInLambda)

> Autocomplete for var keyword not supported in Lambda parameter
> --
>
> Key: NETBEANS-862
> URL: https://issues.apache.org/jira/browse/NETBEANS-862
> Project: NetBeans
>  Issue Type: Bug
>Reporter: ARUNAVA SINHA
>Assignee: ARUNAVA SINHA
>Priority: Minor
>  Labels: JDK11-VarInLambda, pull-request-available
>
> Auto-complete(CTL+ space)  for var keyword in not happening in Lambda 
> parameter (JDK-11). Cursor is at caret position.
> IntBinaryOperator calc2 = (var x,  ^ y ) -> x+y;
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-862) Autocomplete for var keyword not supported in Lambda parameter

2018-06-25 Thread ARUNAVA SINHA (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ARUNAVA SINHA updated NETBEANS-862:
---
Description: 
Auto-complete(CTL+ space)  for var keyword in not happening in Lambda parameter 
(JDK-11). Cursor is at caret position.

IntBinaryOperator calc2 = (var x,  ^ y ) -> x+y;

 

  was:
Auto-complete for var keyword in not happening in Lambda parameter (JDK-11). 
Cursor is at caret position.

IntBinaryOperator calc2 = (var x,  ^ y ) -> x+y;

 


> Autocomplete for var keyword not supported in Lambda parameter
> --
>
> Key: NETBEANS-862
> URL: https://issues.apache.org/jira/browse/NETBEANS-862
> Project: NetBeans
>  Issue Type: Bug
>Reporter: ARUNAVA SINHA
>Assignee: ARUNAVA SINHA
>Priority: Minor
>  Labels: JDK11-VarInLambda
>
> Auto-complete(CTL+ space)  for var keyword in not happening in Lambda 
> parameter (JDK-11). Cursor is at caret position.
> IntBinaryOperator calc2 = (var x,  ^ y ) -> x+y;
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-862) Autocomplete for var keyword not supported in Lambda parameter

2018-06-25 Thread ARUNAVA SINHA (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ARUNAVA SINHA updated NETBEANS-862:
---
Description: 
Auto-complete for var keyword in not happening in Lambda parameter (JDK-11). 
Cursor is at caret position.

IntBinaryOperator calc2 = (var x,  ^ y ) -> x+y;

 

  was:
Auto-complete for var keyword in not happening in Lambda parameter (JDK-11). 
Cursor is at caret position.

IntBinaryOperator calc2 = (int  x,   va^ y ) -> x+y;

 


> Autocomplete for var keyword not supported in Lambda parameter
> --
>
> Key: NETBEANS-862
> URL: https://issues.apache.org/jira/browse/NETBEANS-862
> Project: NetBeans
>  Issue Type: Bug
>Reporter: ARUNAVA SINHA
>Assignee: ARUNAVA SINHA
>Priority: Minor
>  Labels: JDK11-VarInLambda
>
> Auto-complete for var keyword in not happening in Lambda parameter (JDK-11). 
> Cursor is at caret position.
> IntBinaryOperator calc2 = (var x,  ^ y ) -> x+y;
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-980) Home/end/up/down do not work properly when word wrapping is enabled

2018-06-25 Thread Eirik Bakke (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-980:
-
Description: 
Caret movements via Home/End and arrow Up/Down keys do not work properly when 
text wrap (especially in "after words" mode) is enabled in the NetBeans editor.

Specific bugs:
1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the 
beginning of the paragraph rather than to the beginning of the current wrap 
line (physical line).
2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the 
beginning of the next wrap line instead of to the end of the current wrap line.
3) Pressing Up has no effect if the preceding wrap line ended before the 
caret's current X position.
4) Pressing Down will move the caret down _two_ lines if the following wrap 
line ended before the caret's current X position (and assuming the wrap line 
two lines down is long enough).
5) Left-clicking the mouse to the right of the end of a wrap line puts the 
caret on the beginning of the next wrap line rather than at the end of the 
current (clicked) wrap line.

The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit 
(UpAction/DownAction/BeginLineAction/EndLineAction).

Bug number 1 above, for the Home action (BeginLineAction), is easy to fix and 
is unrelated to the others. (Don't allow Utilities.getRowFirstNonWhite to move 
the caret before lineStartPos.)

Bugs 2-5 above all relate to what caret position is mapped to the "infinite" 
horizontal space that follows each wrap line. With NetBeans' current behavior, 
this space corresponds to a caret position directly following the last 
character of a wrap line. This caret position, however, is physically mapped 
(and painted) on the beginning of the following wrap line, which confuses the 
logic for the End, Up, and Down actions. I suspect that if bug 5 is fixed, then 
bugs 2-4 might "fix themselves" as well.

For bug 5, I think the best solution when clicking the space beyond the end of 
a wrap line would be to move the caret to right _before_ the last character on 
the wrap line. This character is usually a space (in word wrap mode), though it 
could also be a hyphen or such if a more advanced word wrapping algorithm is 
used (proposed in the pull request for NETBEANS-977). The resulting behavior 
would be similar to that of a default JTextArea, or jEdit (though these never 
break words on anything else than a space). Another solution would be to do 
like the TextEdit app on MacOS, where the cursor is placed _after_ the last 
character on the wrap line, like NetBeans currently does, but with a backwards 
bias such that the cursor is painted on the end of the current wrap line 
instead of on the beginning of the next wrap line. The latter is probably 
harder to implement, and is not really necessary.

To test the above bugs:
1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
set "Line Wrap" to "After words". Click OK.
2) Create a new plain text file and paste in the paragraph "SHORTWORD 
LONGWORD SHORTWORD LUUUNGWORD".
3) Resize the editor window so that the paragraph gets split into four wrap 
lines (one word on each wrap line--i.e. make the editor a little wider than the 
long word).
4) For each bugs 1-4 listed above, position the caret right after "...ONG", 
then press the relevant key to test.
5) To test bug 5 above, click the mouse to the right of the first, second, or 
third wrap line.

Tested in NetBeans 9.0 rc1.

  was:
Caret movements via Home/End and arrow Up/Down keys do not work properly when 
text wrap (especially in "after words" mode) is enabled in the NetBeans editor.

Specific bugs:
1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the 
beginning of the paragraph rather than to the beginning of the current wrap 
line (physical line).
2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the 
beginning of the next wrap line instead of to the end of the current wrap line.
3) Pressing Up has no effect if the preceding wrap line ended before the 
caret's current X position.
4) Pressing Down will move the caret down _two_ lines if the following wrap 
line ended before the caret's current X position (and assuming the wrap line 
two lines down is long enough).
5) Left-clicking the mouse to the right of the end of a wrap line puts the 
caret on the beginning of the next wrap line rather than at the end of the 
current (clicked) wrap line.

The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit 
(UpAction/DownAction/BeginLineAction/EndLineAction).

Bug number 1 above, for the Home action (BeginLineAction), is easy to fix and 
is unrelated to the others. (Don't allow Utilities.getRowFirstNonWhite to move 
the caret before lineStartPos.)

Bugs 2-5 above all relate to what caret position is mapped to the 

[jira] [Updated] (NETBEANS-980) Home/end/up/down do not work properly when word wrapping is enabled

2018-06-25 Thread Eirik Bakke (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-980:
-
Description: 
Caret movements via Home/End and arrow Up/Down keys do not work properly when 
text wrap (especially in "after words" mode) is enabled in the NetBeans editor.

Specific bugs:
1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the 
beginning of the paragraph rather than to the beginning of the current wrap 
line (physical line).
2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the 
beginning of the next wrap line instead of to the end of the current wrap line.
3) Pressing Up has no effect if the preceding wrap line ended before the 
caret's current X position.
4) Pressing Down will move the caret down _two_ lines if the following wrap 
line ended before the caret's current X position (and assuming the wrap line 
two lines down is long enough).
5) Left-clicking the mouse to the right of the end of a wrap line puts the 
caret on the beginning of the next wrap line rather than at the end of the 
current (clicked) wrap line.

The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit 
(UpAction/DownAction/BeginLineAction/EndLineAction).

Bug number 1 above, for the Home action (BeginLineAction), is easy to fix and 
is unrelated to the others. (Don't allow Utilities.getRowFirstNonWhite to move 
the caret before lineStartPos.)

Bugs 2-5 above all relate to what caret position is mapped to the "infinite" 
horizontal space that follows each wrap line. With NetBeans' current behavior, 
this space corresponds to a caret position directly following the last 
character of a wrap line. This caret position, however, is physically mapped 
(and painted) on the beginning of the following wrap line, which confuses the 
logic for the End, Up, and Down actions. I suspect that if bug 5 is fixed, then 
bugs 2-4 might "fix themselves" as well.

For bug 5, I think the best solution when clicking the space beyond the end of 
a wrap line would be to move the caret to right _before_ the last character on 
the wrap line. This character is usually a space (in word wrap mode), though it 
could also be a hyphen or such if a more advanced word wrapping algorithm is 
used (proposed in the pull request for NETBEANS-977). The resulting behavior 
would be similar to that of a default JTextArea, or jEdit (though these never 
break words on anything else than a space). Another solution would be to do 
like the TextEdit app on MacOS, where the cursor is placed _after_ the last 
character on the wrap line, but with a backwards bias such that the cursor is 
painted on the end of the current wrap line instead of on the beginning of the 
next wrap line. The latter is probably harder to implement, and is not really 
necessary.

To test the above bugs:
1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
set "Line Wrap" to "After words". Click OK.
2) Create a new plain text file and paste in the paragraph "SHORTWORD 
LONGWORD SHORTWORD LUUUNGWORD".
3) Resize the editor window so that the paragraph gets split into four wrap 
lines (one word on each wrap line--i.e. make the editor a little wider than the 
long word).
4) For each bugs 1-4 listed above, position the caret right after "...ONG", 
then press the relevant key to test.
5) To test bug 5 above, click the mouse to the right of the first, second, or 
third wrap line.

Tested in NetBeans 9.0 rc1.

  was:
Caret movements via Home/End and arrow Up/Down keys do not work properly when 
text wrap (especially in "after words" mode) is enabled in the NetBeans editor.

Specific bugs:
1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the 
beginning of the paragraph rather than to the beginning of the current wrap 
line (physical line).
2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the 
beginning of the next wrap line instead of to the end of the current wrap line.
3) Pressing Up has no effect if the preceding wrap line ended before the 
caret's current X position.
4) Pressing Down will move the caret down _two_ lines if the following wrap 
line ended before the caret's current X position (and assuming the wrap line 
two lines down is long enough).
5) Left-clicking the mouse to the right of the end of a wrap line puts the 
caret on the beginning of the next wrap line rather than at the end of the 
current (clicked) wrap line.

The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit 
(UpAction/DownAction/BeginLineAction/EndLineAction).

Bug number 1 above, for the Home action (BeginLineAction), is easy to fix and 
is unrelated to the others. (Don't allow Utilities.getRowFirstNonWhite to move 
the caret before lineStartPos.)

Bugs 2-5 above all relate to what caret position is mapped to the "infinite" 
horizontal space that 

[jira] [Updated] (NETBEANS-980) Home/end/up/down do not work properly when word wrapping is enabled

2018-06-25 Thread Eirik Bakke (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-980:
-
Description: 
Caret movements via Home/End and arrow Up/Down keys do not work properly when 
text wrap (especially in "after words" mode) is enabled in the NetBeans editor.

Specific bugs:
1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the 
beginning of the paragraph rather than to the beginning of the current wrap 
line (physical line).
2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the 
beginning of the next wrap line instead of to the end of the current wrap line.
3) Pressing Up has no effect if the preceding wrap line ended before the 
caret's current X position.
4) Pressing Down will move the caret down _two_ lines if the following wrap 
line ended before the caret's current X position (and assuming the wrap line 
two lines down is long enough).
5) Left-clicking the mouse to the right of the end of a wrap line puts the 
caret on the beginning of the next wrap line rather than at the end of the 
current (clicked) wrap line.

The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit 
(UpAction/DownAction/BeginLineAction/EndLineAction).

Bug number 1 above, for the Home action (BeginLineAction), is easy to fix and 
is unrelated to the others. (Don't allow Utilities.getRowFirstNonWhite to move 
the caret before lineStartPos.)

Bugs 2-5 above all relate to what caret position is mapped to the "infinite" 
horizontal space that follows each wrap line. With NetBeans' current behavior, 
this space corresponds to a caret position directly following the last 
character of a wrap line. This caret position, however, is physically mapped 
(and painted) on the beginning of the following wrap line, which confuses the 
logic for the End, Up, and Down actions. I suspect that if bug 5 is fixed, then 
bugs 2-4 might "fix themselves" as well.

For bug 5, I think the best solution when clicking the space beyond the end of 
a wrap line would be to move the caret to right _before_ the last character on 
the wrap line. This character is usually a space (in word wrap mode), though it 
could also be a hyphen or such if a more advanced word wrapping algorithm is 
used (proposed in the pull request for NETBEANS-977). This behavior would be 
similar to that of a default JTextArea, or jEdit (neither which break words on 
anything else than a space). Another solution would be to do like the TextEdit 
app on MacOS, where the cursor is placed _after_ the last character on the wrap 
line, but with a backwards bias such that the cursor is painted on the end of 
the current wrap line instead of on the beginning of the next wrap line. The 
latter is probably harder to implement, and is not really necessary.

To test the above bugs:
1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
set "Line Wrap" to "After words". Click OK.
2) Create a new plain text file and paste in the paragraph "SHORTWORD 
LONGWORD SHORTWORD LUUUNGWORD".
3) Resize the editor window so that the paragraph gets split into four wrap 
lines (one word on each wrap line--i.e. make the editor a little wider than the 
long word).
4) For each bugs 1-4 listed above, position the caret right after "...ONG", 
then press the relevant key to test.
5) To test bug 5 above, click the mouse to the right of the first, second, or 
third wrap line.

Tested in NetBeans 9.0 rc1.

  was:
Caret movements via Home/End and arrow Up/Down keys do not work properly when 
text wrap (especially in "after words" mode) is enabled in the NetBeans editor.

Specific bugs:
1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the 
beginning of the paragraph rather than to the beginning of the current wrap 
line (physical line).
2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the 
beginning of the next wrap line instead of to the end of the current wrap line.
3) Pressing Up has no effect if the preceding wrap line ended before the 
caret's current X position.
4) Pressing Down will move the caret down _two_ lines if the following wrap 
line ended before the caret's current X position (and assuming the wrap line 
two lines down is long enough).
5) Left-clicking the mouse to the right of the end of a wrap line puts the 
caret on the beginning of the next wrap line rather than at the end of the 
current (clicked) wrap line.

The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit 
(UpAction/DownAction/BeginLineAction/EndLineAction).

Bug number 1 above, for the Home action (BeginLineAction), is easy to fix 
(don't allow Utilities.getRowFirstNonWhite to move cursor before lineStartPos) 
and is unrelated to the others.

Bugs 2-5 above all relate to what caret position is mapped to the "infinite" 
horizontal space that follows each wrap 

[jira] [Updated] (NETBEANS-980) Home/end/up/down do not work properly when word wrapping is enabled

2018-06-25 Thread Eirik Bakke (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-980:
-
Description: 
Caret movements via Home/End and arrow Up/Down keys do not work properly when 
text wrap (especially in "after words" mode) is enabled in the NetBeans editor.

Specific bugs:
1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the 
beginning of the paragraph rather than to the beginning of the current wrap 
line (physical line).
2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the 
beginning of the next wrap line instead of to the end of the current wrap line.
3) Pressing Up has no effect if the preceding wrap line ended before the 
caret's current X position.
4) Pressing Down will move the caret down _two_ lines if the following wrap 
line ended before the caret's current X position (and assuming the wrap line 
two lines down is long enough).
5) Left-clicking the mouse to the right of the end of a wrap line puts the 
caret on the beginning of the next wrap line rather than at the end of the 
current (clicked) wrap line.

The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit 
(UpAction/DownAction/BeginLineAction/EndLineAction).

Bug number 1 above, for the Home action (BeginLineAction), is easy to fix 
(don't allow Utilities.getRowFirstNonWhite to move cursor before lineStartPos) 
and is unrelated to the others.

Bugs 2-5 above all relate to what caret position is mapped to the "infinite" 
horizontal space that follows each wrap line. With NetBeans' current behavior, 
this space corresponds to a caret position directly following the last 
character of a wrap line. This caret position, however, is physically mapped 
(and painted) on the beginning of the following wrap line, which confuses the 
logic for the End, Up, and Down actions. I suspect that if bug 5 is fixed, then 
bugs 2-4 might "fix themselves" as well.

For bug 5, I think the best solution when clicking the space beyond the end of 
a wrap line would be to move the caret to right _before_ the last character on 
the wrap line. This character is usually a space (in word wrap mode), though it 
could also be a hyphen or such if a more advanced word wrapping algorithm is 
used (proposed in the pull request for NETBEANS-977). This behavior would be 
similar to that of a default JTextArea, or jEdit (neither which break words on 
anything else than a space). Another solution would be to do like the TextEdit 
app on MacOS, where the cursor is placed _after_ the last character on the wrap 
line, but with a backwards bias such that the cursor is painted on the end of 
the current wrap line instead of on the beginning of the next wrap line. The 
latter is probably harder to implement, and is not really necessary.

To test the above bugs:
1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
set "Line Wrap" to "After words". Click OK.
2) Create a new plain text file and paste in the paragraph "SHORTWORD 
LONGWORD SHORTWORD LUUUNGWORD".
3) Resize the editor window so that the paragraph gets split into four wrap 
lines (one word on each wrap line--i.e. make the editor a little wider than the 
long word).
4) For each bugs 1-4 listed above, position the caret right after "...ONG", 
then press the relevant key to test.
5) To test bug 5 above, click the mouse to the right of the first, second, or 
third wrap line.

Tested in NetBeans 9.0 rc1.

  was:
Caret movements via Home/End and arrow Up/Down keys do not work properly when 
text wrap (especially in "after words" mode) is enabled in the NetBeans editor.

Specific bugs:
1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the 
beginning of the paragraph rather than to the beginning of the current wrap 
line (physical line).
2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the 
beginning of the next wrap line instead of to the end of the current wrap line.
3) Pressing Up has no effect if the preceding wrap line ended before the 
caret's current X position.
4) Pressing Down will move the caret down _two_ lines if the following wrap 
line ended before the caret's current X position (and assuming the wrap line 
two lines down is longer).
5) Left-clicking the mouse to the right of the end of a wrap line puts the 
caret on the beginning of the next wrap line rather than at the end of the 
current (clicked) wrap line.

The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit 
(UpAction/DownAction/BeginLineAction/EndLineAction).

Bug number 1 above, for the Home action (BeginLineAction), is easy to fix 
(don't allow Utilities.getRowFirstNonWhite to move cursor before lineStartPos) 
and is unrelated to the others.

Bugs 2-5 above all relate to what caret position is mapped to the "infinite" 
horizontal space that follows each wrap line. 

[jira] [Updated] (NETBEANS-980) Home/end/up/down do not work properly when word wrapping is enabled

2018-06-25 Thread Eirik Bakke (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-980:
-
Summary: Home/end/up/down do not work properly when word wrapping is 
enabled  (was: Home/end/up/down does not work properly when word wrapping is 
enabled)

> Home/end/up/down do not work properly when word wrapping is enabled
> ---
>
> Key: NETBEANS-980
> URL: https://issues.apache.org/jira/browse/NETBEANS-980
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Other, editor - Painting  Printing
>Affects Versions: 9.0
>Reporter: Eirik Bakke
>Priority: Major
>
> Caret movements via Home/End and arrow Up/Down keys do not work properly when 
> text wrap (especially in "after words" mode) is enabled in the NetBeans 
> editor.
> Specific bugs:
> 1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the 
> beginning of the paragraph rather than to the beginning of the current wrap 
> line (physical line).
> 2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the 
> beginning of the next wrap line instead of to the end of the current wrap 
> line.
> 3) Pressing Up has no effect if the preceding wrap line ended before the 
> caret's current X position.
> 4) Pressing Down will move the caret down _two_ lines if the following wrap 
> line ended before the caret's current X position (and assuming the wrap line 
> two lines down is longer).
> 5) Left-clicking the mouse to the right of the end of a wrap line puts the 
> caret on the beginning of the next wrap line rather than at the end of the 
> current (clicked) wrap line.
> The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit 
> (UpAction/DownAction/BeginLineAction/EndLineAction).
> Bug number 1 above, for the Home action (BeginLineAction), is easy to fix 
> (don't allow Utilities.getRowFirstNonWhite to move cursor before 
> lineStartPos) and is unrelated to the others.
> Bugs 2-5 above all relate to what caret position is mapped to the "infinite" 
> horizontal space that follows each wrap line. With NetBeans' current 
> behavior, this space corresponds to a caret position directly following the 
> last character of a wrap line. This caret position, however, is physically 
> mapped (and painted) on the beginning of the following wrap line, which 
> confuses the logic for the End, Up, and Down actions. I suspect that if bug 5 
> is fixed, then bugs 2-4 might "fix themselves" as well.
> For bug 5, I think the best solution when clicking the space beyond the end 
> of a wrap line would be to move the caret to right _before_ the last 
> character on the wrap line. This character is usually a space (in word wrap 
> mode), though it could also be a hyphen or such if a more advanced word 
> wrapping algorithm is used (proposed in the pull request for NETBEANS-977). 
> This behavior would be similar to that of a default JTextArea, or jEdit 
> (neither which break words on anything else than a space). Another solution 
> would be to do like the TextEdit app on MacOS, where the cursor is placed 
> _after_ the last character on the wrap line, but with a backwards bias such 
> that the cursor is painted on the end of the current wrap line instead of on 
> the beginning of the next wrap line. The latter is probably harder to 
> implement, and is not really necessary.
> To test the above bugs:
> 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
> set "Line Wrap" to "After words". Click OK.
> 2) Create a new plain text file and paste in the paragraph "SHORTWORD 
> LONGWORD SHORTWORD LUUUNGWORD".
> 3) Resize the editor window so that the paragraph gets split into four wrap 
> lines (one word on each wrap line--i.e. make the editor a little wider than 
> the long word).
> 4) For each bugs 1-4 listed above, position the caret right after 
> "...ONG", then press the relevant key to test.
> 5) To test bug 5 above, click the mouse to the right of the first, second, or 
> third wrap line.
> Tested in NetBeans 9.0 rc1.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-980) Home/end/up/down does not work properly when word wrapping is enabled

2018-06-25 Thread Eirik Bakke (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-980:
-
Description: 
Caret movements via Home/End and arrow Up/Down keys do not work properly when 
text wrap (especially in "after words" mode) is enabled in the NetBeans editor.

Specific bugs:
1) Pressing Home (Fn+Left Arrow on MacBooks) will bring the text caret to the 
beginning of the paragraph rather than to the beginning of the current wrap 
line (physical line).
2) Pressing End (Fn+Right Arrow on MacBooks) will bring the text caret to the 
beginning of the next wrap line instead of to the end of the current wrap line.
3) Pressing Up has no effect if the preceding wrap line ended before the 
caret's current X position.
4) Pressing Down will move the caret down _two_ lines if the following wrap 
line ended before the caret's current X position (and assuming the wrap line 
two lines down is longer).
5) Left-clicking the mouse to the right of the end of a wrap line puts the 
caret on the beginning of the next wrap line rather than at the end of the 
current (clicked) wrap line.

The Home/End/Up/Down actions are all implemented in o.n.editor.BaseKit 
(UpAction/DownAction/BeginLineAction/EndLineAction).

Bug number 1 above, for the Home action (BeginLineAction), is easy to fix 
(don't allow Utilities.getRowFirstNonWhite to move cursor before lineStartPos) 
and is unrelated to the others.

Bugs 2-5 above all relate to what caret position is mapped to the "infinite" 
horizontal space that follows each wrap line. With NetBeans' current behavior, 
this space corresponds to a caret position directly following the last 
character of a wrap line. This caret position, however, is physically mapped 
(and painted) on the beginning of the following wrap line, which confuses the 
logic for the End, Up, and Down actions. I suspect that if bug 5 is fixed, then 
bugs 2-4 might "fix themselves" as well.

For bug 5, I think the best solution when clicking the space beyond the end of 
a wrap line would be to move the caret to right _before_ the last character on 
the wrap line. This character is usually a space (in word wrap mode), though it 
could also be a hyphen or such if a more advanced word wrapping algorithm is 
used (proposed in the pull request for NETBEANS-977). This behavior would be 
similar to that of a default JTextArea, or jEdit (neither which break words on 
anything else than a space). Another solution would be to do like the TextEdit 
app on MacOS, where the cursor is placed _after_ the last character on the wrap 
line, but with a backwards bias such that the cursor is painted on the end of 
the current wrap line instead of on the beginning of the next wrap line. The 
latter is probably harder to implement, and is not really necessary.

To test the above bugs:
1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
set "Line Wrap" to "After words". Click OK.
2) Create a new plain text file and paste in the paragraph "SHORTWORD 
LONGWORD SHORTWORD LUUUNGWORD".
3) Resize the editor window so that the paragraph gets split into four wrap 
lines (one word on each wrap line--i.e. make the editor a little wider than the 
long word).
4) For each bugs 1-4 listed above, position the caret right after "...ONG", 
then press the relevant key to test.
5) To test bug 5 above, click the mouse to the right of the first, second, or 
third wrap line.

Tested in NetBeans 9.0 rc1.

  was:
If line wrap is enabled, and the text caret is located in a wrapped paragraph, 
the up/down arrow keys cannot be used to move the caret up/down to another wrap 
line if the target wrap line is shorter than the current caret position. Either 
nothing happens, or the caret may skip the shorter wrap lines and step multiple 
wrap lines up/down.

To reproduce:
1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
set "Line Wrap" to "After words". Click OK.
2) Create a new plain text file and paste in the paragraph "SHORTWORD 
LONGWORD SHORTWORD LUUUNGWORD".
3) Resize the editor window so that the paragraph gets split into three wrap 
lines (one word on each wrap line--i.e. make the editor a little wider than the 
long word).
4) Position the cursor right after "...ONG"
5) Press the "Up" arrow. Nothing happens (expected would be to the caret to 
move up to the end of the previous wrap line).
6) Press the "Down" arrow. This moves the caret _two_ wrap lines down instead 
of to the end of the next wrap line.

Tested in NetBeans 9.0 rc1.


> Home/end/up/down does not work properly when word wrapping is enabled
> -
>
> Key: NETBEANS-980
> URL: https://issues.apache.org/jira/browse/NETBEANS-980
> Project: NetBeans
>  Issue Type: Bug
>  

[jira] [Updated] (NETBEANS-980) Home/end/up/down does not work properly when word wrapping is enabled

2018-06-25 Thread Eirik Bakke (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke updated NETBEANS-980:
-
Summary: Home/end/up/down does not work properly when word wrapping is 
enabled  (was: Cannot arrow up/down to shorter word-wrapped line in editor)

> Home/end/up/down does not work properly when word wrapping is enabled
> -
>
> Key: NETBEANS-980
> URL: https://issues.apache.org/jira/browse/NETBEANS-980
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Other, editor - Painting  Printing
>Affects Versions: 9.0
>Reporter: Eirik Bakke
>Priority: Major
>
> If line wrap is enabled, and the text caret is located in a wrapped 
> paragraph, the up/down arrow keys cannot be used to move the caret up/down to 
> another wrap line if the target wrap line is shorter than the current caret 
> position. Either nothing happens, or the caret may skip the shorter wrap 
> lines and step multiple wrap lines up/down.
> To reproduce:
> 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
> set "Line Wrap" to "After words". Click OK.
> 2) Create a new plain text file and paste in the paragraph "SHORTWORD 
> LONGWORD SHORTWORD LUUUNGWORD".
> 3) Resize the editor window so that the paragraph gets split into three wrap 
> lines (one word on each wrap line--i.e. make the editor a little wider than 
> the long word).
> 4) Position the cursor right after "...ONG"
> 5) Press the "Up" arrow. Nothing happens (expected would be to the caret to 
> move up to the end of the previous wrap line).
> 6) Press the "Down" arrow. This moves the caret _two_ wrap lines down instead 
> of to the end of the next wrap line.
> Tested in NetBeans 9.0 rc1.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Closed] (NETBEANS-979) With line wrap enabled, cursor at end of line is painted at beginning of next line instead

2018-06-25 Thread Eirik Bakke (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eirik Bakke closed NETBEANS-979.

   Resolution: Duplicate
Fix Version/s: (was: 9.0)

Having done a little work on this, the underlying issue is the same as for 
NETBEANS-980, so I'm closing this one and making all new comments on that one.

> With line wrap enabled, cursor at end of line is painted at beginning of next 
> line instead
> --
>
> Key: NETBEANS-979
> URL: https://issues.apache.org/jira/browse/NETBEANS-979
> Project: NetBeans
>  Issue Type: Bug
>  Components: editor - Painting  Printing
>Reporter: Eirik Bakke
>Priority: Major
>
> In an editor with line wrap enabled, the cursor is shown at the wrong 
> physical location whenever it is supposed to be located at the end of a wrap 
> line. Instead of being painted at the end of the wrap line, it is painted at 
> the beginning of the following line. This causes the behavior of keyboard 
> shortcuts like "End" and "Up" to seem nonsensical to the user, although they 
> might well be behaving correctly wrt. the physical location of the cursor 
> (the character offset).
> To reproduce:
> 1) Go to Options/Preferences->Editor->Formatting, select "All Languages" and 
> set "Line Wrap" to "After words". Click OK.
> 2) Create a new plain text file and open it in the editor.
> 3) Type some gibberish into the editor on a single line that is long enough 
> to be broken into several break lines.
> 4) With the cursor before the first character of the first wrap line in the 
> paragraph, press the "End" key (Command+Right on MacBook keyboards). The 
> cursor appears to move one line down, which is unexpected. From looking at 
> this situation, the user would now assume that they could press the "Up" key 
> to move the cursor back to the previous break line, but this will not change 
> the cursor position (because the cursor is logically on the previous line).
> 5) Another unexpected example: Pressing Home anywhere in a paragraph will 
> move the cursor to the first character on the paragraph rather than at the 
> first character of the wrap line. (This might indicate that the problem is 
> more than just a paint bug, though.)
> Originally reported in BugZilla at 
> https://netbeans.org/bugzilla/show_bug.cgi?id=242115 . Still reproducible on 
> NetBeans 9.0 rc1.
> See also https://issues.apache.org/jira/browse/NETBEANS-980 .



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Commented] (NETBEANS-168) Background scanning process needs a rethink

2018-06-25 Thread Christian Lenz (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16521974#comment-16521974
 ] 

Christian Lenz commented on NETBEANS-168:
-

Will try to find a big OSS project to test it with this.

> Background scanning process needs a rethink
> ---
>
> Key: NETBEANS-168
> URL: https://issues.apache.org/jira/browse/NETBEANS-168
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - Performance, java - Platform, platform - Execution
>Affects Versions: 8.2, Next
> Environment: NetBeans 8.2, Windows 10 x64
>Reporter: Christian Lenz
>Priority: Critical
>
> Often, while cloning, switching branch, merging, opening etc. etc. NetBeans 
> starts Background scanning for changes, but it is not real background, 
> because everything what you want to do then, like changing the branch, 
> commit, push, pull, open project, delete or whatever, is blocking by this 
> task and you can't cancel it, because it is essential.
> Either we need to rethink about this process like to make everything or most 
> of the stuff doing things in parallel or the task should really be 
> cancelable. It is a pain in the ass for big projects when they start to scan 
> for changes. 
> It is a real world case because you acan see it when you work on NetBeans 
> modules.
> Cheers
> Chris



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Commented] (NETBEANS-168) Background scanning process needs a rethink

2018-06-25 Thread Christian Lenz (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16521975#comment-16521975
 ] 

Christian Lenz commented on NETBEANS-168:
-

Could be PHP related or smth else. Only guessing.

> Background scanning process needs a rethink
> ---
>
> Key: NETBEANS-168
> URL: https://issues.apache.org/jira/browse/NETBEANS-168
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - Performance, java - Platform, platform - Execution
>Affects Versions: 8.2, Next
> Environment: NetBeans 8.2, Windows 10 x64
>Reporter: Christian Lenz
>Priority: Critical
>
> Often, while cloning, switching branch, merging, opening etc. etc. NetBeans 
> starts Background scanning for changes, but it is not real background, 
> because everything what you want to do then, like changing the branch, 
> commit, push, pull, open project, delete or whatever, is blocking by this 
> task and you can't cancel it, because it is essential.
> Either we need to rethink about this process like to make everything or most 
> of the stuff doing things in parallel or the task should really be 
> cancelable. It is a pain in the ass for big projects when they start to scan 
> for changes. 
> It is a real world case because you acan see it when you work on NetBeans 
> modules.
> Cheers
> Chris



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Commented] (NETBEANS-967) java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location

2018-06-25 Thread Jacco van Weert (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16521976#comment-16521976
 ] 

Jacco van Weert commented on NETBEANS-967:
--

Same for me... I have multiple monitors, but it doesn't matter on which screen 
NB is running, the same issue.

 

> java.awt.IllegalComponentStateException: component must be showing on the 
> screen to determine its location
> --
>
> Key: NETBEANS-967
> URL: https://issues.apache.org/jira/browse/NETBEANS-967
> Project: NetBeans
>  Issue Type: Bug
>  Components: java - Editor
>Affects Versions: 9.0
> Environment: Windows10
>Reporter: Jacco van Weert
>Priority: Major
>
> A lot of times I get this exception when CTRL+click to a method or browsing 
> through the sourcecode.
> It's terrible!
>  
>  
> java.awt.IllegalComponentStateException: component must be showing on the 
> screen to determine its location
>  at java.awt.Component.getLocationOnScreen_NoTreeLock(Component.java:2062)
>  at java.awt.Component.getLocationOnScreen(Component.java:2036)
>  at 
> javax.swing.text.JTextComponent$InputMethodRequestsHandler.getTextLocation(JTextComponent.java:4643)
>  at sun.awt.im.InputMethodContext.getTextLocation(InputMethodContext.java:278)
>  at sun.awt.windows.WInputMethod$1.run(WInputMethod.java:588)
>  at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
>  at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
>  at java.awt.EventQueue.access$500(EventQueue.java:97)
>  at java.awt.EventQueue$3.run(EventQueue.java:709)
>  at java.awt.EventQueue$3.run(EventQueue.java:703)
>  at java.security.AccessController.doPrivileged(Native Method)
>  at 
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
>  at 
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:90)
>  at java.awt.EventQueue$4.run(EventQueue.java:733)
>  at java.awt.EventQueue$4.run(EventQueue.java:731)
>  at java.security.AccessController.doPrivileged(Native Method)
>  at 
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
>  at java.awt.EventQueue.dispatchEvent(EventQueue.java:730)
>  at 
> org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:136)
> [catch] at 
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
>  at 
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
>  at 
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
>  at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
>  at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
>  at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Commented] (NETBEANS-931) OutOfMemory after a night of stand-by

2018-06-25 Thread Luca Mambretti (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16521931#comment-16521931
 ] 

Luca Mambretti commented on NETBEANS-931:
-

The file I sent originally was already compressed and comes down to roughly 156 
MB.

I do not regularly use Telegram, so can I ask for any other means of transfer, 
I'll add another we-trasfer link [https://we.tl/uNs1zJBntx] just in case you 
manage to download that

> OutOfMemory after a night of stand-by
> -
>
> Key: NETBEANS-931
> URL: https://issues.apache.org/jira/browse/NETBEANS-931
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 9.0
>Reporter: Luca Mambretti
>Priority: Critical
> Attachments: messages.log, uigestures.xml
>
>
> After a full day of work I left the system running (it had manifested the 
> errors described in NETBEANS-901).
>  
> The day after it was out of commission with OOM.
>  
> attached IDE logs and gestures, I also have the heap dump but it's 1.5 gigs 
> so I doubt I'll be able to attach it (sent it thru a WeTransfer link for now)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists