I am working with a VB.NET user control which should use the hand cursor when the mouse is over it.
This bit does work - when the cursor is on top of the control, we get a hand. A bug has been reported by the customer, which I have been able to reproduce, that when the hand cursor is changed in the Windows mouse settings it still uses the Windows default cursor. The arrow cursor does update.
Me.Parent.Control.Cursor = Cursors.Hand
What am I missing to get this to use the correct one? I'm guessing there's an easier way than going to the registry to find the hand cursor for the current user and loading that in as a custom cursor object?
I have tried to do a Google search for this, but I am only finding results for different environments (CSS, etc), or articles about what a cursor is.
Related
I have written an app that makes extensive use of custom right-click menus on an Access form. The code works great and the user loves it, but lately I am having trouble making it work properly.
In earlier versions of Access it worked well, but newer version seem much more limited in how many items can be put in such menus. The documentation is silent on the matter, and nobody in any newsgroup has had any useful ideas, but I regularly get random error about stack space, out of memory, and general lockups when populating the menus. Doing a C&R used to help, but now even that is not enough, and some menus I can no longer populate at all.
I tried building an app that just built menus until it crashed, to get some idea of what the limits may be, and I am well below what that indicated, but the experimental app had nothing else, while the real app has a great deal else.
Is there any information on how much stuff can be put into these menus, and what the menus share space with? There may be something I can do another way to make more room for the menus. I tried moving all code out of the form, leaving only event stubs that called routines in standard code modules, but that did not help.
And how are they stored/activated? The app is MUCH slower to load when it has these menus, even though no code is running on start-up.
********** Edited to add this:
I use VBA to create a menu, like this:
Application.CommandBars.Add "RCStat", msoBarPopup, False, False
then add it to a control. like this:
Application.CommandBars.cboStat.ShortcutMenuBar = "RCStat"
I add controls (only popups and buttons) like this:
Application.CommandBars.Controls.Add(type:=msoControlPopup)
Application.CommandBars.Controls.Add(type:=msoControlButton, Parameter:="StatKod = 77")
It runs perfectly and the menu items work exactly as expected, except that it bombs after adding some number of controls. It doesn't seem to matter where I add them, just the total number of added controls hits some undefined threshold, and the app crashes.
I got the original code from Getz, Litwin and Gilbert, 2000 edition. Back then, it worked great. But as the versions advance and the app accumulates data, it is becoming less and less functional. However, there are only around 10,000 records, and the app itself is less than 100MB - nowhere close to any of Access's upper size limits.
Pete,
I've done quite a bit of work with shortcut menus, and created the Access Shortcut Tool about 5 years ago, but have never attempted a menu with so many controls although some have 3 or 4 levels.
I am not aware of any restrictions on the number of elements in the commandbars collection, but I find that shortcut menus with too many options, like lists and combo boxes with too many items, are difficult for users to navigate. I generally break these up into segments and use buttons in the form header to display the appropriate menu. Sorry I'm unable to provide anything more helpful.
Dale
We have a commercial product, Total Access Components, that includes as one of its 30 components a right click popup menu that can include icons and font styles.
Here's the info for the popup menu control: https://fmsinc.com/MicrosoftAccess/controls/components/popup-menu/
There's a free trial if you want to try it.
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.
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.
The radio recently broke in our bedroom and as a result my missus now listen to various radio stations through her laptop. She moans that visiting various pages and clicking the 'listen' link is a bit of a pain. (Note to self: Must buy new radio!)
In the meantime, I have made a 'radio player' in VB 2008 Express, which is nothing more than 6 buttons down the left hand side of the 'player' I have created and a Web Browser Control on the right hand side.
Clicking each button links to the relevant player of the station she wants to listen to. (Being a newbie to VB and programming, I'm quite proud with what I've achieved so far!!)
Anyway, one station I do link to gives an "Are you sure you want to navigate away from this page" prompt: This one:
http://www.mygoldmusic.co.uk/
Well, thats the homepage of the site anyway, the actual player is here:
(Oops, seems I can only post one link! The actual player opens on-click of the 'listen' button then, sorry to be a pain!)
My question is: Is there a way to suppress this message in VB, or even auto-answer OK somehow?
The other sites I have linked to do not display this message, they just navigate away quite happily. Clicking OK on the prompt is no real hardship either, I hear you say, but in the interests of usability, I would just like it to navigate away from the site/player without prompting.
Remember, I'm using Microsoft Visual Basic 2008 Express Edition. (I say that, because I've come across loads of sites that tell you how to do it with JavaScript, just not VB!)
I've got to the point of thinking it can't be done, but here's hoping!
Any help/advice would be greatly appreciated. And, sorry for the lengthy question. Hope it gives you enough info on what I'm trying to achieve.
Thanks in advance again.
J.
The only way I can think of is to actually modify the DOM of the page in the WebBrowser control. That popup is loading when the "window.onunload" event fires. You should be able to override this behaviour by modifying the DOM.
The HTML document DOM (Document Object Model, essentially an object graph of the page structure) is stored in the WebBrowser.HTMLDocument property. Unfortunately, that specific property isn't available to the .NET version. It IS available to COM however, so through some very ugly and messy code you might be able to suppress the event.
The following code should be able to access the COM property containing the HTML DOM. The type returned is IHTMLDocument2, although you'll note that the class itself will return an object. You might need to add a reference to mshtml.dll to get the IHTMLDocument2 interface access the properties of this in a reasonable way.
Dim domDocument As IHTMLDocument2 = webBrowser.HtmlDocument.DomDocument
You can then access the OnUnload event (which sits on the "window" element, one above the document). Unfortunately, the plot thickens a bit here (I did say it was going to be ugly) because you need to pass a IDispatch object to the onunload event. I've never done this specifically but I found a write-up at the following link that provides some samples and should point you in the right direction: http://blogs.msdn.com/cgarcia/archive/2009/08/28/handling-dom-events-in-a-c-activex.aspx
You should be able to follow a similar approach but simply do nothing in the handler method, which should suppress the javascript alert you are getting.
Get the handle to the dialog and destroy it. Use FindWindow and send a WM_CLOSE message to it.
I'm currently developing a PowerBuilder application and noticed that each window features a 'ParentWindow' function. However, there doesn't seem to be a 'ChildWindows' or anything like that.
Unfortunately, the Documentation at sybase.com just says that these base classes are not documented. Maybe somebody figured it out anyway, using some sort of reflection?
What I would like to do (this is the reason why I'm interested in the API of the generic baseclasses like PowerObject or WindowObject) is to recursively iterate over all GUI elements (windows, tables, buttons, check boxes, you name it) using PowerScript in PowerBuilder 11.0. Does anybody know how to do this (whether this is possible at all)?
For the API (functions, properties, etc...) of any system object, including PowerObject or WindowObject:
Open the Object Browser (icon on the PowerBar toolbar, or under the Tools menu item in later versions of PB)
Go to the System tab
(not essential, but for bonus points) Right click on the left pane and select Show Hierarchy from the menu
Select the object in question on the left pane
Double click the Properties, Events or Functions headers in the right pane to expand the list.
As for iterating over all GUI elements, the easiest way is to maintain a list of window handles in the Open and Close events of your common ancestor to all your windows (you do have a common ancestor to all your windows, don't you?) and go through the list, recursing through the Control[] arrays (note that UserObjects, Tabs and TabPages have Control[] arrays as well as Windows). Unless you're going to mess around with Windows APIs to get all the window handles belonging to a process, there's no easy way to get this list without maintaining this list yourself.
Good luck,
Terry.