I am trying to learn VB.Net coming off from experience using VBA. I was wondering if there was something similar that uses the "Debug.Print" from VBA in VB.Net. Also is there also something that is similar to the immediate window that exists in VB.Net? I was also looking for that too.
A great question. (have no idea why the poor sports here are down voting this question – what a miserable bunch – they must have missed their morning coffee.
So, yes, there is a immediate window.
More interesting? The same key in Access/VBA (ctrl-g) will in fact launch the immediate window for you! (so yes to the immediate window, and same key (ctrl-g) to show it).
So this allows a “similar” approach in vb.net
In VBA:
Debug.print "Hello"
In vb.net
Debug.print ("Hello")
So, just keep in mind that WHEN you using debug.print in vb.net, you have use () for the expression. So parentheses "()" are requied. (in VBA that was optional).
ONE MORE very important tip:
By default, debug.print output NOT directed to the immediate window.
So, while in VS, go tools->options.
On the left pane choose “Debbuging”, and then output window.
In that area, check this box:
So, once you do this?
During debugging, the immediate window should appear. (if not, then hit ctrl-g).
The windows unfortunately does hide WHEN you stop debugging, but you CAN hit ctrl-g again.
And WHAT VERY FEW vb.net folks know that VBA Access folks know?
You can in the immediate window even while not debugging, type in a code call such as:
VS will flip into debug mode, and call/run that code! So you can even call + use subs and functions you created (or built in ones) without EVEN being in debug mode (this is exactly what long time VBA developers do, and vb.net supports this wonderful approach to development.
This great idea from VBA is thus avaialble in vb.net,and few seem to know this great tool.
It not “quite” as fluid and easy as the immediate window in Access we all come to know and love, but checking the above box, and using the “long time” ctrl-g key to open/show the immediate window goes a VERY long way and lays out a nice welcome mat of helping VBA developers making the jump to vb.net.
In addition to ctrl-g, you can display the window by going:
from IDE. debug->windows->immedate.
You can use
#If DEBUG Then
'do something
#End If
This is ignored in Release build.
Related
I'm writing a VB program where I want to be able to "push" an Exit button with a keyboard shortcut to close the program. I understand that if I put an & in the text of the button (E&xit), I can create a Alt-X shortcut to exit.
I've written programs where it's worked before; it's simple, but now it's not working. In fact, it's not even underlining the x in the text on the button. It's like a setting is telling it to be ignored. (I'm using the latest version of MS Visual Studio.)
I have found that if I turn on the form setting KeyPreview=True, it will work, but the x is still not underlined, so there is no visual indication of the shortcut being available. I feel like I'm missing some setting or switch that make this activate normally. Can someone explain or point me in the right direction? Thanks.
jmcilhinney, well, now it's working, both on new and existing apps, even with keypreview turned off. I think there was something strange going on with Visual Studio that day. Other parts of my program (with KeyPress handling) were not working correctly either at that time. Then suddenly everything started to behave as expected. Or maybe it was something I was doing with Keypress that messed up the Access Keys. I wish I could explain better, but now I can't reproduce the problem.
i want to build some automation code that will select some item from a menubar of minimized (or non-active) window.
I have tried to do it with ControlSend function by sending some keys like alt and directions, but it's not working...
See my example:
I want to select the item "Select All", for this i wrote this code:
WinWaitActive("")
Send("{ALTDOWN}{ALTUP}{RIGHT}{ENTER}{DOWN}{DOWN}{ENTER}")
The code above works good, but i want that it will work when the window is not active, so i wrote this line:
ControlSend("", "", "Term Class1", "{ALTDOWN}{ALTUP}{RIGHT}{ENTER}{DOWN}{DOWN}{ENTER}")
This is not working for me, do you have some idea how can i implement it?
I too was trying to work with minimized windows but have since switched from windows so i wont be able to test things out for you. I have been told (and from experience) that you cant use control send (or the mouse click alternative which is called "control click") on applications that do not come stock with windows (applications that dont come with the computer, to put it simply).
However i came upon this (https://www.autoitscript.com/forum/topic/7112-minimized-clicking-great-for-game-bots/) which seems to be a 3rd party add in that lets you do just that, i tried using it but could not make it fit my needs. Perhaps you can, I would try to get it working for you but again, i dumped windows. The above link is the best candidate i have found, and by far the most promising after i searched and tested for about a month a while back, Good Luck.
EDIT: As always, i do not promise anything from the above link, you use it at your own risk.
OK, this might be a bit of a generic and repeated non-code question but the latest article I can find about this is from over 2 years ago, so I'm wondering if there's been a fix or an update or maybe some clever dude out there has cracked the secret to curing this.
Every time I extend my screen while Excel (2007, 2010 or 2013) is running, and every time I unplug from an extension while Excel is running, my ActiveX controls are rendered useless, because with each click they either shrink or get bigger, depending on if I extended or unplugged.
This happens until I close the Excel application and restart it, unfortunately if I've saved it while the buttons are bigger/smaller they might end up stuck like that.
There is a thread here which has a bit code to help deal with the issue but quite frankly I'm hoping by now, two years later, someone has a slightly more efficient method of dealing with it.
I've took to using hyperlinks to run macros now but that's no good for my drop-boxes and things. And for me personally, I can just make sure I close Excel before extending/unplugging, but the real issue is I'm developing apps for people around the company and it's starting to cause problems with these damned buttons.
Does anyone know of a definitive fix for this yet?
If you only need ActiveX buttons to run macros, use Shapes instead. You can assign macros to a s shape's Click event. Right-click the shape and select "Assign Macro".
I am trying to write a macro to log into a website but I keep getting stopped by a security alert pop up that requires me to click OK to continue. Any idea what lines to put in to make it click on the OK button so I can proceed to the site?
If you want to stick with VBA, a few options come to mind. The quick and dirty approach would just be to use Sendkeys, and send Enter. It's super unreliable though, but may work in your specific case.
Another option is using windows APIs to send/post the relevant message to the window. See here
The final option I'll offer is considering Authotkey as a language stand-in. It makes this type of interaction really easy. It has COM support, so you can still use Excel, just like VBA.
http://www.contextures.com/excelvbasendkeys.html
SendKeys should be able to do this I think...
SendKeys "~"
O
I am trying to develop a little macro for PowerPoint using VBA. However, the "Development Environment" is an absolute nightmare!
The worst: there seems to be no real good way to generate debug output! I read that the Debug.Print output is supposed to go to the Immediate Window, but nothing appears there! So I am currently using MsgBox to generate debug messages. :-(
What's also really bad is, that errors in a macro always crash PPT. So one has to wait, until it is gone and then one has to restart it again and get rid of all the Recovery attempts. This always takes ages!
If I set On Error Resume Next it doesn't crash - at least not as often - but then things just silently don't work and I can't see what and why things go wrong (unless I plaster the code with MsgBox calls, but that requires 100'000 clicks during each execution).
And running the code in the debugger and single stepping trough the code doesn't work, either, since my macro refers to the current "ActivePresentation" and that doesn't seem to exist unless one starts the slideshow mode. So this debugging is driving me nuts!
Is this really the only possibility or environment to develop VBA code in? At least some idea re. debug output, anyone?
M.
The worst: there seems to be no real good way to generate debug output! I read that the Debug.Print output is supposed to go to the Immediate Window, but nothing appears there!
At the risk of sounding insulting (which I don't intend!) do you have the Immediate window open? While in the IDE, press Ctrl+G to see if anything new appears. If so, that's the Immediate window.
What's also really bad is, that errors in a macro always crash PPT.
Not ordinarily, no. It can happen that way, of course; your code might be triggering a bug in PPT. Heaven knows, I ran into enough of that in PPT 2002 and 2007. If you're using reasonable error handling and still running into errors that crash PPT, stepping through the code as it runs should allow you at least to narrow it down to the line or two that cause the crash.
And running the code in the debugger and single stepping trough the code doesn't work, either, since my macro refers to the current "ActivePresentation" and that doesn't seem to exist unless one starts the slideshow mode.
Again, no. The ActivePresentation refers to whatever presentation has focus in the app, whether it's in slide show or any other view. If your code's in one presentation and its' supposed to be acting on another, that can cause some confusion, but you simply need to switch to normal view, make sure the presentation you want to access is visible (I'd make sure not to have several in view) then Alt+F11 to return to the IDE and run your code.
All of these suggestions apply to any Windows version of PPT, going back to Office 97 (Mac? Thinks different. If you're using a Mac, mention that. There are a few differences but for the most part, everything above applies except for the Alt+F11).
If none of this seems to help on your setup, it may be time to do a repair of Office.