Is there any way I can use multiple monitors with ACCESS.

[jpl458]

I have 3 monitors and 2 of them are not carrying their weight, and it would make life easier for me if I could move stuff to other windows.

Thanks

 

[plog]

On behalf of everyone--huh? Lot's of immediate questions and responses:

Yes.

Multiple means more than 1. You have 3 monitors, minus 2 monitors that "are not carrying their weight" = 1 monitor. How will you have multiple monitors in the future?

Define "are not carrying their weight".

This isn't an Access question but a Windows one. Controlling monitors is an operating system issue.

Exactly what is the issue?

 

[jpl458]

On behalf of everyone--huh? Lot's of immediate questions and responses:

Yes.

Multiple means more than 1. You have 3 monitors, minus 2 monitors that "are not carrying their weight" = 1 monitor. How will you have multiple monitors in the future?

Define "are not carrying their weight".

This isn't an Access question but a Windows one. Controlling monitors is an operating system issue.

Exactly what is the issue?

If the monitors did not work, I wouldn't be asking the question in this forum. The monitors work, but I can only use 1 of then when in ACCESS. If you read the initial question I asked it is simple enough. Now, as simply as I can state it, can you use more than 1 monitor with ACCESS. Let me be clearer, if I am in ACCESS, is there a way I can drag an open windows in ACCESS to a different monitor, thereby increasing my ACCESS work space.

 

[theDBguy]

is there a way I can drag an open windows in ACCESS to a different monitor, thereby increasing my ACCESS work space.

I don't see why not. What happens when you try?

 

[plog]

I deleted my prior post because I was partially wrong.

You can "undock" forms and reports by setting their Pop Up property to Yes. You can then move them anywhere you want.

Tables and queries must remain inside the bounds of Access itself. You open Access on monitor A, maximize it and open Query1. You cannot move Query1 to monitor B because Access is not on monitor B. If you unmaximize Access as a whole, and resize Access so that it takes up monitor A & monitor B you can then move that query to monitor B but it still must be inside Access as a whole.

 

[jpl458]

If the monitors did not work, I wouldn't be asking the question in this forum. The monitors work, but I can only use 1 of then when in ACCESS. If you read the initial question I asked it is simple enough. Now, as simply as I can state it, can you use more than 1 monitor with ACCESS. Let me be clearer, if I am in ACCESS, is there a way I can drag an open windows in ACCESS to a different monitor, thereby increasing my ACCESS work space.

I don't see why not. What happens when you try?

Can't move anything to another monitor. I grab it and it stays put. I can move the whole shebang, but an individual part. It appears to me that ACESS will only work on one screen. The exception is the the VBA window which always appears on the monitor on the right side. I sorta thought that if that part could open on another monitor then what about a form, or an open table, or a different form, etc.

 

[jpl458]

I deleted my prior post because I was partially wrong.

You can "undock" forms and reports by setting their Pop Up property to Yes. You can then move them anywhere you want.

Tables and queries must remain inside the bounds of Access itself. You open Access on monitor A, maximize it and open Query1. You cannot move Query1 to monitor B because Access is not on monitor B. If you unmaximize Access as a whole, and resize Access so that it takes up monitor A & monitor B you can then move that query to monitor B but it still must be inside Access as a whole.

Thanks a lot. That will help

 

[jpl458]

I just tried the popup thing and that works great.

Thanks again

 

[The_Doc_Man]

The other part of the answer is that you will have some difficulty moving Access elements indiscriminately because many of the displayed items are child windows of the Access parent window. This "child window" status has implications for resource sharing - specifically including memory AND the screen resource that defines the boundaries in which display frames can be created.

The "pop-up" status makes the pop-up a "rogue" window that has its own resources because it can't rely on the resources already in use by normal Access windows. (It couldn't be guaranteed to pop up to the top of the display stack without that "pop-up" status, for example.)

 

[June7]

In fact, some have 'lost' popups because they would open on the other monitor instead of right in front of them above the Access app. Some dialogs will open to that last position they were closed from and that could be another monitor.

 

[GPGeorge]

If the monitors did not work, I wouldn't be asking the question in this forum. The monitors work, but I can only use 1 of then when in ACCESS. If you read the initial question I asked it is simple enough. Now, as simply as I can state it, can you use more than 1 monitor with ACCESS. Let me be clearer, if I am in ACCESS, is there a way I can drag an open windows in ACCESS to a different monitor, thereby increasing my ACCESS work space.

I do it all the time. I have only 2 monitors, though. I can have a form open in one and the VBE open in the other, for example.

That said, there's another approach you could take.

Open two or three instances of the accdb. Open one form in each instance. Now you can drag one two a second monitor.

Granted, that's less flexible than what you seem to desire, but it is an option.

 

[jpl458]

I do it all the time. I have only 2 monitors, though. I can have a form open in one and the VBE open in the other, for example.

That said, there's another approach you could take.

Open two or three instances of the accdb. Open one form in each instance. Now you can drag one two a second monitor.

Granted, that's less flexible than what you seem to desire, but it is an option.

I played with it last night and it seems to be sufficient, but June7 raises some concerns about bad things that can happen if you are not careful. I've gotten used to having three monitors when writing code; one for the app, one for the code, and one for Google, where I can look up stuff, and send questions to you nice folks. In addition having 3 monitors is really awesome In MS Flight Simulator.

 

[The_Doc_Man]

Now you have to admit that having a screen free for a Google search or a forum search is pretty useful. The other two screens? You've got some advice here that will help. The discussion about sharing of resources is one that folks don't normally consider, but basically, the process that starts an app "owns" the resources. You could probably "cheat" a little bit by using a virtual desktop for which you could set the parameters, but there is a second little issue that rears its ugly head. Access uses a unit call "twips" for all of its screen layout measurements, AND it uses 16-bit counters for each such measurement. A twip is a unit equaling 1440 per inch. If you have 22.75 inches, that is 32760 twips. Modern display screens easily reach 23 or 24 inches in screen width. The old screen I'm using is 20 1/8 inches wide. The issue is that you cannot display something wider than 22.75 inches anyway. Therefore, if you have, say, 40 inches width on two screens, you would barely be able to use them anyway.

 

[jpl458]

Now you have to admit that having a screen free for a Google search or a forum search is pretty useful. The other two screens? You've got some advice here that will help. The discussion about sharing of resources is one that folks don't normally consider, but basically, the process that starts an app "owns" the resources. You could probably "cheat" a little bit by using a virtual desktop for which you could set the parameters, but there is a second little issue that rears its ugly head. Access uses a unit call "twips" for all of its screen layout measurements, AND it uses 16-bit counters for each such measurement. A twip is a unit equaling 1440 per inch. If you have 22.75 inches, that is 32760 twips. Modern display screens easily reach 23 or 24 inches in screen width. The old screen I'm using is 20 1/8 inches wide. The issue is that you cannot display something wider than 22.75 inches anyway. Therefore, if you have, say, 40 inches width on two screens, you would barely be able to use them anyway.

Thanks again.

 

[Pat Hartman]

As Doc mentioned, Access has two "windows". One for the GUI and the other for VBA. Objects are sub windows of one or the other. I don't like popup forms because they are too annoying for words during development. Generally, I have one monitor showing the GUI and the second showing VBA. That works pretty well. At one client site, I had a third monitor and that was my laptop. I used that for email and everything else. At home I have just the two. At that same client site, most of the employees were analysts and heavy Excel users so they replaced my two monitors with one of the super-wide curved monitors. Access would abend if you moved something too fast but I really hated it because I couldn't really see the screen without turning my head so it didn't help. I went back to the three monitor setup with the two large monitors and the laptop acting as the third.

One other option that you might prefer if you have two same sized monitors, is you can open the GUI across BOTH monitors. Just drag the Access GUI window and resize it. Then use the third for VBA. That gives you a huge amount of space for various queries, tables, etc to all be open while you are developing. Of course, you need to be working in Overlapping Windows mode rather than Tabbed Documents mode for this to even be an option for you I also dislike developing in tabbed view so I use Overlapping Windows all the time because swapping is too annoying.

For distribution of the final app, stick to an interface that will work with a single monitor. Users get too confused when you let them have multiple windows open at one time. In the situations where I want to do that, I open the second as a dialog so that the user can still see the base form and move the dialog around if it covers too much of the base form but the user has to close the popup to go back to the main form.

Tabs are probably the best option when you have a lot of data that you want to have available all the time.

 

[jpl458]

As Doc mentioned, Access has two "windows". One for the GUI and the other for VBA. Objects are sub windows of one or the other. I don't like popup forms because they are too annoying for words during development. Generally, I have one monitor showing the GUI and the second showing VBA. That works pretty well. At one client site, I had a third monitor and that was my laptop. I used that for email and everything else. At home I have just the two. At that same client site, most of the employees were analysts and heavy Excel users so they replaced my two monitors with one of the super-wide curved monitors. Access would abend if you moved something too fast but I really hated it because I couldn't really see the screen without turning my head so it didn't help. I went back to the three monitor setup with the two large monitors and the laptop acting as the third.

One other option that you might prefer if you have two same sized monitors, is you can open the GUI across BOTH monitors. Just drag the Access GUI window and resize it. Then use the third for VBA. That gives you a huge amount of space for various queries, tables, etc to all be open while you are developing. Of course, you need to be working in Overlapping Windows mode rather than Tabbed Documents mode for this to even be an option for you I also dislike developing in tabbed view so I use Overlapping Windows all the time because swapping is too annoying.

For distribution of the final app, stick to an interface that will work with a single monitor. Users get too confused when you let them have multiple windows open at one time. In the situations where I want to do that, I open the second as a dialog so that the user can still see the base form and move the dialog around if it covers too much of the base form but the user has to close the popup to go back to the main form.

Tabs are probably the best option when you have a lot of data that you want to have available all the time.

I found that popup is a pain in the patoot when developing. I am learning 2 things at once, what the work is that I am writing code for, which is kind of amorphou; not defined well, and then I am not a wizard with event level programming. I've written a mile of code in assemblers ( I'm dating myself), and I did some ACCESS work after I retired, but it was simple stuff. In 360/370 IBM Assembler code there were only 24 instructions, and you carried a green folding card around at all times that had everything you needed to know about mainframes. But there were no graphics, we were basically shuffling 80 column cards around, and printing reports. The first mainframe I wrote code for had 8 k of memory. The only bad thing is, using all the monitors for development, I have to watch/listen to TV on my laptop when I work. You're are right about the distribution only using one monitor, the people that will be using this are not technical giants. Thanks for the time and the prose, Il be referencing it along the way.

 

[Pat Hartman]

Knowing how to program can be an impediment to learning how to use Access. I wrote COBOL for years before discovering Access. But at least I worked mostly with CICS and IMS/DC so the transaction concept was familiar to me. The CICS transactions were very similar in concept to forms because of their interface with the user but not as pretty. Here's a link about the most important form event - BeforeUpdate it. It's long but I hope it will be helpful with understanding where certain types of code should be placed. You don't need to create an account to view it.

Bad Data is Bad for Business - Pat & Tony - Video 1

screencast-o-matic.com

 

[jpl458]

Knowing how to program can be an impediment to learning how to use Access. I wrote COBOL for years before discovering Access. But at least I worked mostly with CICS and IMS/DC so the transaction concept was familiar to me. The CICS transactions were very similar in concept to forms because of their interface with the user but not as pretty. Here's a link about the most important form event - BeforeUpdate it. It's long but I hope it will be helpful with understanding where certain types of code should be placed. You don't need to create an account to view it.

Bad Data is Bad for Business - Pat & Tony - Video 1

screencast-o-matic.com

This may sound silly, but the part about the transition that bothered me most, was there was no real beginning to the code in ACCESS, ala BALR *,0 in 360 Assembler. In those days there was a mainline of code, that you only left when you went to a subroutine , BR *, R5. But I am making progress, and it is more understandable and way more productive. My oldest son is a Python wizzard and says that I think at too low a level. But I can see that if you really familiar with ACCESS you can vomit front end applications. I must say that Python is intriguing, from what I have read and bits I've tried. Did you ever expand the COBOL instructions to see the underlying Assembler? I did once and some of the underlying code was pretty inefficient. Example Equate was really bad, but that was when machine time was considered expensive, thus promoting desk checking of your code for errors. Now let the machine/compiler find the crap.

Thanks for the note.

 

[Pat Hartman]

The "missing" mainline disturbed me in the beginning also. What you have to get your head around is that THERE IS A MAINLINE. You just don't see it. The mainline is the hidden part of the Class module for the form which is standard and does all the standard stuff that is needed with every form to fill the controls and set the colors and and lock/unlock or hide/show controls and save the record and move to the next record, etc, etc, etc. The mainline code has "hooks" in it. These are places which link to events and if some event happens, the "mainline" code will execute any "user" code you have added for the event. Take a look at the names of the events. They deal with user interactions that cause the form to need to do something. So, essentially, the event code you write is a bunch of subroutines called by the hidden mainline

And you are absolutely correct. If you understand how Access works well enough to take advantage of what Access does for you, you can "vomit" front end applications. VBA is a fairly easy language because it is pretty high level and actually similar in a lot of respects to COBOL. When I was writing COBOL, I had a couple dozen or so templates. So, I never started from ground zero. I could pick the template and flesh out the details. Access is a little like that. Keep in mind though that you have to know your place. There are things that YOU have to do and there are things, that you have to allow Access to do. For example, Access doesn't know anything about your business rules. So, validation is mostly your responsibility. Defining certain properties at the table level helps with basic things like whether or not a field is required, but you need to fill in the details and the Validation rules at the table level are way too limited to be much use. So, whenever you are tempted to write code because you can, stand back and ask yourself, did the super designers who created Access in the beginning think about this and did they give me an easy way to do it with property settings or a function? If not, then try a query. Your final option is code. As I tell everyone, I've written my million lines of code and I don't need the practice so I never automatically write code that Access has written for me. One simple example is record navigation. Everyone seems to love to create their own navigation controls. Ok, once you've created the code and the button images you like you can make a template to reuse but Access has built in navigation controls that do everything you could possibly want. The question is does the look of the navigation bar offend you? More importantly, does it offend your user? If he is OK with it, don't spend his money to create your own version of something Access does for free.

Did you ever expand the COBOL instructions to see the underlying Assembler?

Every single day. I always included the BAL in the compiler print out so if I had to debug the program, I could use the memory dump and follow the logic to see what variables contained what values when the abend happened. I actually found a bug in the COBOL compiler that I got to report to IBM and was thanked profusely for the report I don't remember the details, it was 45 years ago, but it had to do with tables and indexes and initial values in a rare case. The generated BAL was wrong! Luckily, I was able to create a work around once I saw it. There was no way I could wait for a compiler fix. One of the hardest things about Access for me in the beginning was not being able to see the "dump" when the program crashed unexpectedly.

As part of my COBOL training program, the BAL class was a required prerequisite for the advanced COBOL class because you couldn't really be a great COBOL programmer unless you understood what was happening under the covers. You had to understand the BAL that got generated and how you could affect it by modifying your COBOL to generate more efficient BAL. It was because of that early training that I can really appreciate what Access is doing for me. Once in a while, I wish Access did things differently but I have learned over the years (and have the scars to prove it) that I can't win in a fight with Access and so I should just get with the program and do it the "Access way" Notice I never mentioned macros as an option. Some expert programmer new to Access thought I meant macros when I was trying to explain the "Access way". But to me, the logic required in macros to do anything except open a report, is so bizarre that I think it is much harder than learning VBA.

Like in my COBOL days, I have procedures that I add to many applications and even a little mini-app to manage lookup tables that goes into most new applications. like this one:

Table Maintenance Mini-app

When you have several lookup tables in an application, it becomes a pain to create separate tables and maintenance forms to manage the contents. This sample is an application that I first developed over 40 years ago, long before Access was a twinkle in Bill's eye. It was constructed using...

www.access-programmers.co.uk

This app started over 40 years ago as COBOL with DB2 and with some refinements over the years, is now Access forms with a BE that depends on the database. Just upload to SQL Server if that is your BE of choice.

 

[moke123]

In addition having 3 monitors is really awesome In MS Flight Simulator.

Wait till you see it in VR.