Title quite much says it all.
In VB6, and in VBA/Access it was possible to hit break key, and jump into debug mode when using the msgbox() command.
Is there a way to do this in vb.net (desktop/winforms) applications?
Often, some code will toss up a dialog box, and it is rather nice then to jump into debug mode as a result of that message box having been displayed.
Edit
Ok, hitting pause button in most applications work, but in this application, when I hit pause, then I get this:
Edit two:
Ok, I have discovered the reason for this behavior. I have the application Frame work box un-checked. The reason for this is I did't want to specify the main application form as startup form, and I desired additional control over what occurs if the main startup form (that I don't specify) is closed. Thus, my main application form is launched via application.Run(my form)
It thus seems that due to starting the main form as a new separate application thread (which is the result of using application.Run(), then you can't use ctrl-break, or more common use/hit the pause button in the IDE to halt the code. Hitting pause will thus display that the application is running a main app thread, which indeed is the case since I use applicaiton.Run() to launch the main form from the classic and traditional Sub Main().
Edit 3
A way to fix this, and enable the pause key to work is to un-check in tools->debugging the [ ] Enable Just My Code. This will thus allow debug mode of the other "main" application thread.
Hmm. [CTRL][BREAK] clears the dialog box. However, clicking the pause button in the IDE will do what you want.
Alternatively, select Debug > Break All from the menu.
When starting our vba-access-application (which is done by a VBE-add-in which starts a VBA-function) we used to close the navigation-pane with this code:
DoCmd.SelectObject acMacro, "Autoexec", True
DoCmd.RunCommand acCmdWindowHide
As I started to use the built-in search/filter bar inside the navigation-pane, this code did not work anymore when the macro "Autoexec" is not visible. So I changed it to:
DoCmd.NavigateTo "acNavigationCategoryObjectType"
DoCmd.RunCommand acCmdWindowHide
This seems to work fine as long as there are any search results left. When I write "nothing with that name" inside the search bar(=the filter), the navigation pane will not close.
Does anyone know a way to close the navigation pane even if there is no search result visible?
DoCmd.NavigateTo "acNavigationCategoryModifiedDate"
DoCmd.NavigateTo "acNavigationCategoryObjectType"
DoCmd.RunCommand acCmdWindowHide
In order for the command DoCmd.RunCommand acCmdWindowHide to successfully close the Navigation Pane, the Navigation Pane must have the focus. But for an Access window to have the focus, a control within the window must have focus. It turns out that the NavigateTo command will never place the focus in the Search textbox, so if the search results are blank and there is nothing to select, then focus will not change to the Navigation Pane (even though technically the Navigation Pane's selected group may have been updated.)
If you play with the Navigation Pane long enough, you'll find that the Navigation search results and textbox are reset when switching between the highest-level Navigation categories. Hence my suggested code... it changes between two Navigation categories so that the search results are cleared during that action, so that the Navigation window will eventually gain focus when one of its listed objects finally gets focus.
(Really, using the NavigateTo command in this case is just a stupid trick to place focus on the Navigation Pane. It's just another glaring deficiency of the Access interface that there is no direct commands/objects for controlling the Navigation Pane.)
I suggest you don't write any code—but just use the built in Access settings to prevent (hide) the nav pane.
So work, then you hold down the shift key during startup.
(shift key by-pass).
The shift key development dance:
You will find that you can launch + develop a lot of code and work on forms/reports without having to exit.
However, you STILL will have done a shift key start-up bypass. The reason of course is that on start up, you code may well hide the ribbon. (Or launch a custom one). Same goes for start-up form—it may run a bunch of code, ask for logon, check table links.
And then there is the start-up settings you have. You likely have a start-up form (you don’t want that running). You likely have un-checked the display nav pane, but you need this during development. And what about if you have a custom ribbon? (Again a setting in tools→options). And use special keys—again turned off for users, but REQUIRED for developers.
And then there is the auto keys macro. This is used to re-purpose the F1 key (help—either disable or launch your own custom help—say a pdf or word file).
And any re-purpose such as say an f12 to popup some custom search box etc.
So, all of these custom setup is going to be rather LARGE amount of settings. Many will be from tools→options (main form, ribbon, etc.). And some will be from your code.
You REALLY (but REALLY) can’t code out all of these settings, and some require a re-start anyway. In a typical application there really going to be a lot of settings that are changed for your users vs you as the developer.
On start-up you thus hold down shift key. This will not only prevent your start up code from running, but ALSO your start up settings – even things like nav pane, and especially the tools→settings area (shift key ignores most of those settings).
So during a day of development, I will do this shift key dance all day long.
However, there are two tricks and shortcuts you can use here that will minimize this exit + re-enter down to a dull roar.
One great tick is to always place a custom compact repair button on the QAT. So QAT button is now ONE mouse click and always available to you. So if I am working on a form in design mode, flipping into view mode will often suffice, but in those cases where I need a full exit + re-start to test? I don’t even save the form, I just do a quick simple one click on that QAT compact + repair button.
One click! (Might have to answer yes to save). At this point, the application will re-start without you having to exit. And you don’t hold down the shift key—so all your start up settings run. You now flipped into user test mode, and it only took ONE mouse click.
This allows you to flip from developer mode and into “user test” mode with ease and only one mouse click.
So you can now run your application as it will appear to the end user.
To flip back into developer mode, just one simple click on your custom C+R button. (And you HOLD down shift key). This will flip you back into developer mode (you nav pane, your function keys, everything and all those start up settings are now ignored – you are free to develop without all those hassles and issues in your way). Full wide open use of Access as if no settings at all occurred.
And as noted, you get a c+r to boot, and you need + want to do that multiple times during the day anyway.
And as noted, for a good many changes, you not have to do this flip and can stay in developer mode.
Of course in some cases your “user mode” will REALLY lock down the Access and thus you have to exit (you lose the QAT trick). So you often be able to jump from developer to user, but not back the other way. Again, you not have to run + test everything in user mode all the time, but often some global variables, start up, password stuff will force this issue on you.
So, in this case?
I use a quick hit of alt+f4 to exit the application. AT this point, the accDB file should STILL be highlighted in the windows explorer. So, now it just a quick tap of the enter key to re-launch the accDB. And if wanting “user mode”, then simply don’t hold down the shift key. Do some testing, now alt+f4, and then a simple quick tap of the enter key (we back to the windows file explore and that accDB file is highlight). However, this time you WILL hold down the shift key, and thus you now back into developer mode.
And often, I will call my start up code before testing.
Ctrl+g (jumps to debug window), type in MyStartup
(MyStartup is assumed to be your first start up routine that does all that setup and THEN launches the main form – so in some applications I don’t use the built in start-up form setting, but use the autoexec macro to call my main start up routine (MyStartup)
So in a good many cases, I don’t have to exit Access to flip into test mode.
And of course some reports and forms can be used, viewed, developed on without having to full run the application with all that “user” start-up code stuff.
So some report might work, but then again it may well require some form to be open for it to work. (Or a system wide function and company name setting may be required + set in your start up code). So how badly you need to exit vs that of being able to do “some” development will often vary here.
So I will say that often I am forced to exit + re-load the application (alt+f4, tap enter key). So it only really 2 key combo to exit out and re-load/re-enter Access.
At the end of the day, if you can’t use that QAT shortcut suggestion, then you will exit + re-enter MANY MANY times during the day.
As noted, for a good number of forms etc., then you can flip between view and design mode. (But you of course be running access without all that start up crap stuff that prevents you the developer from working).
The simple matter is at the end of the day, there is going to be FAR MORE settings then just the nav pane (or lack of) that going to mess up your development process. So, the above shift key dance and QAT suggestion ALSO solves all of the OTHER many settings, and does so without you having to write one line of code to deal with this issue.
Of course, once all is working, then you will compile the application down to an accDE. And then apply the shift key by-pass code to that to lock the application further down.
After I updated from 2017.1 to 2017.2 my cursor navigation outside the editor is lagging.
Examples are the project view and the VSC Dialog (log, local changes aka changelists, etc.)
When I traverse with my cursor from top to bottom and back the cursor sometimes stops and nothing happens. When I wait some time it is movable again.
Funny thing is that IntelliJ itself does not seem to be freezing - it's just the cursor movement that stops.
That is because I'm able to click with my mouse anything in the list I'm traversing through, even when the cursor is freezing again I am always able to at least click the desired field/option.
I'd love to provide some kind of detail log but am not able to find any.
I've just installed the Rubberduck VBE add-in v2.0.11.2453 (MSIL) on Windows 10 OS.
When I open a macro-enabled Excel workbook in Excel and launch the VBA editor, Rubberduck starts but all commands under the Rubberduck menu are disabled.
What am I doing wrong?
Disclaimer: I'm heavily involved with the development of the Rubberduck add-in.
You did nothing wrong =)
In earlier alpha 2.x releases we discovered that launching the initial parse on startup was causing problems (violent crashes), because the add-in was, essentially, ready before the VBE had finished setting up the object model for the project(s) loaded in the IDE. Basically the VBE loads its add-ins before it completely finishes constructing itself, so we can't just launch a parse task right on startup.
So we disabled the initial/automatic parse, that's why it needs to be done manually (for now).
The Rubberduck commandbar (docked at the top of the IDE by default, just below the main commandbar) contains a "refresh" button:
Clicking that button will change the parser state from "Pending" / "En attente" to "Ready" / "Prêt" (after going through a number of states).
Most Rubberduck commands will be enabled as soon as the state is "Parsed" (which doesn't last very long - it switches to "Resolving identifiers" quite immediately after), and the refactorings get enabled on "Ready" state (even before inspections finish running).
You will also find that "refresh" command button in the toolstrip of the Code Explorer, Test Explorer, Inspection Results and Todo Explorer toolwindows.
You should be able to browse/navigate the code and use the VBE while Rubberduck is working in the background, but please note that modifying code while Rubberduck is parsing it is possibly going to result in some parser error states; we assume that the code in the IDE is compilable =)
Think of that button as "Okay ducky, I've done code changes, now sync up with the IDE": the add-in needs to know the exact in-editor location of every single token in order to work as it should. Refactoring or applying an inspection quick-fix on de-synchronized parser state is definitely a bad idea!
That said, disabling all menus on startup was kind of lazy (and clumsy too: for example the hotkey for displaying the inspection results and code explorer toolwindows will work even though the menus are disabled) - we'll fix that by next release, and the initial parse should be automatic again, too (we'll make it start after a delay, to give the VBE a chance to finish starting up).
I'm a frontend developer and I have a multi-monitor setup. I have HTML code on one monitor and CSS code on another monitor.
To achieve that, I drag a tab out of IntelliJ IDEA window, so that the tab opens in a separate window.
My problem is that the secondary window lacks a menu:
Menu access hot keys (e.g. Alt+V) won't work. I can't make use of the main window's menu either because when I click it, the focus switches to the active tab of the main window.
How do I access the menu when I'm working in IDEA's secondary window?
This feature is currently not available in IntelliJ IDEA.
The alternatives I could think of to do what you want:
Consider raising a feature request on http://youtrack.jetbrains.com/
Do you think it's possible that you might not miss the menu on the detached tab if instead of accessing functionality through the menu, you did the same through keyboard shortcuts?
Personally, being a keyboard junkie, I have not felt the lack of a menu on the detached tab.
Even though Eclipse allows you to create a new window for the same workspace, I had some issues with it ( for eg: if you set a breakpoint in a file in Window 1, and started a debug session from Window 2, then the file would be re-opened in Window 2 when the breakpoint is hit) and feel that the Intellij IDEA implementation works better.
(Warning! The most Hacky suggestion) Assuming you are using Windows, there are a number of ways in which you could extend the single IntelliJ window across the two monitors and then instead of detaching a tab, you could do a 'Split Vertically' in that single window. With the slider between the tabs positioned just right, it will seem you have two windows opened with each of them having a menu.
To extend a window across two monitors see : How can you maximize a window on to dual monitors in Windows 7 or use one of the multi-monitor tools listed here or here ( I vaguely recall that it was the latter 'zbar' that I used to extend a window during my eclipse days).
Believe it or not, I have done this with Eclipse when I was sick of guessing where the file-with-the-breakpoint would open up :)