это прекрасно, что можно настроить под себя. проблема в том, что любая настройка, как отключение перспектив или восстановление скрытых пунктов меню, каждый раз требует гугла и 10 мин долботни. посмотрите, например, как включить тулбар по умолчанию, чтобы он не исчезал при перезапуске.
кстати в NB спец-окна и тулбары активируются при помощи плагинов, при этом основная раскладка остается прозрачной между всеми режимами.
Rebuild Project после вашей подсказки нашел, в горячих клавишах (которые тоже почему-то настраиваются в свойствах окон (Windows->Preferences), как и все остальные системные настройки). в меню Project, как и в контекстном меню проекта, этого пункта нет. ну ОК, забиндил на Ctrl+F10 как у себя в NB/MPLabX. в фокусе редактора вместо пересборки открывается контекстное меню, в фокусе панели проектов — активируется верхнее меню. с контекстным оказывается — конфликт горячей комбинации, о чем Eclipse вежливо умолчал. устраняю. теперь верхнее меню активируется всегда, по Ctrl+F10. пересборка так и не работает. все, спасибо.
с этим сталкиваешься в первые полчаса использования среды. копать глубже уже как-то и смысла по-моему нет
в долгосрочной перспективе — да. только это другой уровень сложности, плюс зависимость от NB API, интеграционное тестирование, публикация, поддержка, обновления,…
кстати, ставить всех на паузу может оказаться полезной ф-цией при отладке многоголовых систем или обмена с ПК
OK.
а если написать внешнюю обертку для GDB, которая будет запускаться из NetBeans, стартовать его самого и OOCD (условно-параллельно), возвращая правильный PID самого GDB, и просто форвардить управляющий траффик?
у меня при запуске OOCD через скрипт GDB как-будто сразу рвется связь. в окне Sessions — Process ID = -1 и Process State = Exited. кнопки отладки остаются, но все заблокированы, кроме завершения сеанса
if (exEnv.isLocal() && Utilities.isWindows()) {
File f = InstalledFileLocator.getDefault().locate("bin/GdbKillProc.exe", "org.netbeans.modules.cnd.debugger.common2", false); // NOI18N
//bz#258406 - NullPointerException at org.netbeans.modules.cnd.debugger.common2.utils.ExecutorCND.interrupt
//looks loke GdbKillProc file could not be located, will just check for null
if (f != null && f.exists()) {
ProcessUtils.execute(exEnv, f.getAbsolutePath(), "-s", "INT", Long.toString(pid)); //NOI18N
}
(комменты авторские как есть)
т.е. GdbKillProc.exe -s INT [pid]
кстати только сейчас понял, что утилита требует правки для использования argv[3] для получения [pid]. забыл пояснить, извиняюсь
скоро обновлю пост, и будет наверное еще пара вопросов по автоматизации запуска OOCD/GDB, что вы выше писали
похоже, получилось.
попробуйте скомпилировать свою утилиту, переименовать в GdbKillProc.exe и подложить в %User%/AppData/Roaming/NetBeans/8.2/bin
кстати, у самописных кнопок и консольной остановки есть фундаментальный недостаток — не позволяют ставить брейкпоинты на лету, т.к. для этого требуется кратковременная остановка стандартным способом
вроде вариант решения нашелся (ниже), но если не сработает, буду иметь в виду.
в принципе, сам Eclipse можно наверное глянуть в исходниках, т.к. все отладочные платфрмы на GCC (даже десктопные) по идее должны использовать этот же механизм
анекдот один напоминает
кстати в NB спец-окна и тулбары активируются при помощи плагинов, при этом основная раскладка остается прозрачной между всеми режимами.
Rebuild Project после вашей подсказки нашел, в горячих клавишах (которые тоже почему-то настраиваются в свойствах окон (Windows->Preferences), как и все остальные системные настройки). в меню Project, как и в контекстном меню проекта, этого пункта нет. ну ОК, забиндил на Ctrl+F10 как у себя в NB/MPLabX. в фокусе редактора вместо пересборки открывается контекстное меню, в фокусе панели проектов — активируется верхнее меню. с контекстным оказывается — конфликт горячей комбинации, о чем Eclipse вежливо умолчал. устраняю. теперь верхнее меню активируется всегда, по Ctrl+F10. пересборка так и не работает. все, спасибо.
с этим сталкиваешься в первые полчаса использования среды. копать глубже уже как-то и смысла по-моему нет
кстати, ставить всех на паузу может оказаться полезной ф-цией при отладке многоголовых систем или обмена с ПК
а если написать внешнюю обертку для GDB, которая будет запускаться из NetBeans, стартовать его самого и OOCD (условно-параллельно), возвращая правильный PID самого GDB, и просто форвардить управляющий траффик?
а что тогда работает?
почему должен быть некорректный?
(комменты авторские как есть)
т.е.
GdbKillProc.exe -s INT [pid]кстати только сейчас понял, что утилита требует правки для использования argv[3] для получения [pid]. забыл пояснить, извиняюсь
скоро обновлю пост, и будет наверное еще пара вопросов по автоматизации запуска OOCD/GDB, что вы выше писали
попробуйте скомпилировать свою утилиту, переименовать в GdbKillProc.exe и подложить в
%User%/AppData/Roaming/NetBeans/8.2/binкстати, у самописных кнопок и консольной остановки есть фундаментальный недостаток — не позволяют ставить брейкпоинты на лету, т.к. для этого требуется кратковременная остановка стандартным способом
в принципе, сам Eclipse можно наверное глянуть в исходниках, т.к. все отладочные платфрмы на GCC (даже десктопные) по идее должны использовать этот же механизм
сложность была в том, чтобы управлять из-под NetBeans
как раз Eclipse, сборка под Linux есть
Из консоли работает, сейчас смотрю как внедрить в стандартную установку с минимальным вмешательством