Change monitor orientation via vba using windows API call.

I am not a big fan of screen "Resizers",...
But you can try this:
http://www.peterssoftware.com/ss.htm

It does not change the monitor resolution directly, ...it adjusts the size of the controls to fit the current resolution...

JeffCoachman

...oh, ...sorry, I did not read fully where you wanted to change the "orientation".

Why cant the user just use the windows key combination:
    Ctrl+Alt (arrow keys)
...to quickly change the Orientation?
http://www.alphr.com/features/391579/how-to-rotate-a-laptop-or-pc-screen-flip-your-display-sideways

JeffCoachman

There is no user... all this computer does is display a jobs board for a manufacturing shop.

I log into the computer via tightVNC from some other computer from time to time to troubleshoot.  The problem is, tight VNC shows the content twisted 90 degrees and half of the monitor content is missing.  The biggest problem is the windows task bar is located on the part of the monitor that is not displayed for some reason tightVNC does not allow/show the "screen resolution" menu when right clicking on the windows desktop.  So I'm kinda out of options other then a command button in the access program itself.

TightVNC does not allow all the options that one would have sitting at the local machine, for instance there is no cut and paste shortcuts when using tight VNC... etc.

One other solution as i type this would be to maybe show the windows taskbar at the top of the screen on the remote comptuer, but that is less than ideal.  I will use that as a possible backup solution.

"for some reason tightVNC does not allow/show the "screen resolution" menu when right clicking on the windows desktop"

Ok

Throw the Control Panel Icon on the desktop, and have it in a place you can double-click it.
Then fire up the Display applet from there.

Or will it not fire up that applet, period?

...or get a monitor that rotates...?
http://www.pcworld.com/article/2042888/review-three-widescreen-hd-monitors-that-pivot-from-portrait-to-landscape.html

@Nick

Good to "see" you again.

At first I thought your suggestion was a very clever workaround.  

First, can't totally do the shortcut thing as the one form in access that is open is actually a popup that is modal and can't be moved resized or closed. It also is basically the size of the whole desktop so almost no desktop real estate is even visible.  But i was thinking I could just launch the control panel screen resolution from the access button using stuff located here:

http://www.sevenforums.com/tutorials/24008-screen-resolution-shortcut-create.html

BUT...  I forgot one additional problem. This computer is not logged in as and admin user AND I have the machine totally locked down with software called "security administrator" that pretty much blocks the user from doing everything and anything in windows except literally open the access program.  Any attempt to open any control panel is immediately going to be blocked by the software, that is also why the right click to said menu is blocked!  Any attempt at opening anything that is windows system related is just not going to work.

I am now even more certain only a VBA call to the API to change the orientation is going to be my only solution.

@Jefferey

Physically moving the monitor does nothing for tightVNC, I could mount the monitor updside on Mars and tight VNC is still going to display the monitor incorrectly on the host. LOL

oK, ...
LOL
;-)

Here's what looks like someone did in C+ code, but I have no idea how to change C+ to VB :(

http://stackoverflow.com/questions/25652812/c-changing-screen-orientation-issue-devmode-dmdisplayorientation-dmdo-90-un 

and another

https://theroadtodelphi.wordpress.com/2011/02/11/changing-screen-orientation-programmatically-using-delphi/

and a third

https://weseetips.wordpress.com/tag/dmdisplayorientation/


Nobody has apparently accomplished via VB however...

Why not use a different remote access program that gives you more control than TightVNC? There are several free ones that are far more feature rich.

Here is a powershell solution which is more my speed...
This would be an acceptable solution.

In many ways, its probably the ideal solution, compared to getting the WinAPI stuff flanged up in VBA.
I've come across many of the same posts you did, and looked at the MSDN stuff about how to do it, and its pretty clear that you need to sew it up very carefully or you'll introduce memory leaks and/or crashes -- and I suspect PowerShell will look after those niceties.

When VBA can't do it natively, it's whatever will work :)
If PS can get it done, run with it!

@Scott

Yes, that is another way to solve the problem but with the powershell solution, on the VNC side, if it's not broke don't fix it!

@Nick

Glad to have a second confirmation on that, that is also my assessment.  I'm just surprised with the rise of tablets, ultra books and orientation switching phones and the like nobody has had the need to force an orientation while running a vb based database.

I'm just surprised with the rise of tablets, ultra books and orientation switching phones and the like nobody has had the need to force an orientation while running a vb based database.

There are questions about auto-resizing forms that get asked occasionally, but there are no good, totally free VBA solutions available.  The usual response is the one you got:
http://www.peterssoftware.com/ss.htm
In general, for Access, you design to the smallest resolution that you know will be in play, and let the chips fall where they may.

The last such question I chimed in on, I asked the Asker to consider the ROI of plowing development time into such resizing.  Perhaps his budget might be better used by throwing some tiny monitors in the bush.  (one of our European friends was horrified -- surely they should be properly recycled!)

So it's not that such questions don't occur, but the reality is if you are looking for adaptive UI, web-based development, and not Access, is where you need to be.  Access doesn't have such facilities and probably never will.

Perhaps his budget might be better used by throwing some tiny monitors in the bush.  (one of our European friends was horrified -- surely they should be properly recycled!)

^ LOL, that made my day!

In general, for Access, you design to the smallest resolution that you know will be in play, and let the chips fall where they may.

I break design rules in my sleep :)  My access database spans 3 monitors at 2560 x 1600 on administrative machines and the same program scales to 1920 x 1080 for the shops.  I like to make access do things it's not supposed to all day long!

Still, it's just screen orientation, and clearly the powershell script does it via some windows mechanism.  My understanding of C+ is that C+ and VB use the same underlying engine, it's all just syntax. And from what I can tell the C+ part of the powershell script uses DEVMODE which appears to be a Device API.  So it's stands to reason that if C+ can call that API, so can VB.

It seems I keep finding myself in uncharted territory often lately.  I'm just happy I found that powershell script.

My understanding of C+ is that C+ and VB use the same underlying engine, it's all just syntax
No.
Now, with C# and VB.NET that's completely true, and if you create managed code in Visual Studio with any language that uses the CLI and uses the .NET framework, that true at the underlying level.

There are big similarities in how the code samples look because they are doing the same thing:  making calls to Windows API to do what you want, and it's the requirements of the API that call the tune.
So it's stands to reason that if C+ can call that API, so can VB.
VBA, though, has a smaller subset of abilities that VB 6 did -- and except for syntax VB.Net is a different monster altogether.
What always holds true is if it can be done from VBScript, it can be done from VBA.
Not vice versa though.
VBScript cannot call WinAPIs

I like to make access do things it's not supposed to all day long!
Nah, that's phrased wrong.
I like to make Access do everything its capable of doing
Which is far more than some folks suspect :)

Interesting, thanks for the clarification.  My knowledge of other languages is quite limited outside the VBA realm.

Yes, I find that there really isn't anything access can't do if you willing to spend the time, do the research, and make it work. It really is quite capable...

You have to remember that VBA is "Visual Basic for Applications", which means that you're working in a flavor of VB that has been customized for use with the specific application (in your case, Access). Many of the C and C++ APIs have been converted for use with VB, and while VBA is very similar to VB, it's not a complete and exact "fit". There are still some APIs that just don't "fit", normally because they return a type of structure or result that VB/VBA cannot understand, or because they manipulate things in a manner that make them unreadable to VB/VBA. In many cases, no one has taken the time to convert the API call to a structure that VB/VBA can understand, either because there is little need for it, or due to one of the limitations suggested above.

So just because you can do something in C or C++ does not mean you can do it in VB (or Java, or any other language).

"I find that there really isn't anything access can't do if you willing to spend the time, do the research, and make it work. It really is quite capable..."

I think perhaps your question would disprove that :). Granted, you were able to make it work with an external call to Powershell ... but you're doing that in Powershell, not in Access.

Interesting, i wasn't aware the the full api isn't available to vba users.  I have close to 100 API calls and never ran into an issue with a particular API that I needed not being accessible, but there is always a first.

Obviously as a small business, we don't have the luxury of programming purity. Yes there does not seem to be a strictly VBA solution to the problem, but I'm sure we can agree in the real world the only thing that matters is a workable solution to a problem, not the elegance of the solution.

VBA < VB < AND NOT ~ VB.NET  ~  C+  Got It :)
   ^
I'm stuck here like it or not.

@Scott

Why not use a different remote access program that gives you more control than TightVNC? There are several free ones that are far more feature rich.

I kinda blew by your statement without at least asking for a recomendation, I'm always interested in other options. Do you have a favorite?

The Windows API calls were basically written for the C/C++ languages. Many have been ported to other languages, like VB, but not all of them (even those that could be ported) - and when you factor in the changes in "bit-ness" (16/32/64), you have thousands upon thousands of API calls available. As mentioned above, it can take time to port them to specific languages, and often those with the knowledge to do so simply don't have the time or inclination. Note that MSFT aren't the ones doing the porting, necessarily. Often that is a developer who really, really had the need to use that particular feature of the API and took the time to figure out how to make the API work for their language.

I'm always interested in other options. Do you have a favorite?

I use ScreenConnect to handle remote access needs, but it's not free (and I'm not sure it's the right "fit" for you). There are many others, however, as evidenced by this Wikipedia article:

https://en.wikipedia.org/wiki/Comparison_of_remote_desktop_software

I just assumed anything API came from MSFT, had no idea that it was more organic than that with 3rd parties chiming in to do the ground work.  With VBA being low on the totem pole, I'm not surprised then that some of the API's are just not converted then.  Obviously, this is not the first time I have struggled with VB not doing what I need natively, which is why I have in the past had to relay on batch files and more recently powershell scripts to fill in the gaps.

I'll check out ScreenConnect, I'm not adverse to paying for things that are uniquely suited.  Also the wikipedia article is excellent, thanks.

All Windows API libraries come from MSFT. They just created them for use with the C/C++ languages, and only ported them as needed. Others have ported some of the API calls as well, so that part is somewhat of a hodge-podge. I don't believe MSFT supports any "ports" of their API calls, regardless of who did the work, but I could be wrong about that.

There doesn't seem to be much in terms of VB solutions on this, the only solution is a C+ version that nobody has converted.  The powershell solution I ran across that I marked as a solution was the one that was the best alternative.