Using Popup and modal on a form But linking it like a subform master/child

[MunroeM]

Hello I was wondering if there is a way to make a form using popup and modal and also have it have the master/child fields like a subform does.



I have attached a pic of several things in my database in hopes that you might be able to help me. The Bottom right is the current popup and modal i have going but when i enter the data in the white fields it asks for the toolboardkitnum to be filled out

Im looking at using the popup and modal method as my previous master and child subform i had worked great but the subform losing focus and saving issue i was running into was killing me.

Thanks for the help

[June7]

A popup/modal form is an independent form - has no connection to the form from which it is called to be opened. So no, the Master/Child Links properties cannot be used in this situation. Passing values between these unconnected forms is not simple.

Maybe should really address "the subform losing focus and saving issue".

[MunroeM]

I’ve been trying to address the losing focus from subform issue for a few days now and I’m just stumped as to where I should from here. It works but it doesn’t. It does what I need but it also saves when I don’t want it to

I’ve included my database maybe if someone wants to take a look and give me suggestions.

I would greatly appreciate any tips

Thanks

[CJ_London]

using popup and modal and also have it have the master/child fields like a subform does.

linkchild/linkmaster properties are the proiperties of a subform control on the main form, not of the subform iteslef. Nearest you can get to this is to either use the openargs property for docmd.openform or have code in your popup which refers to the 'main' form. either way, you will need code in your popup to accomplish what linkchild /master does.

[ItsMe]

...It does what I need but it also saves when I don’t want it to...

In circumstances like this I will employ unbound controls. Like June7 mentioned, bound controls will do stuff.

I won't belabor the point that the Master/Child Link properties are the public interface for a Black Box that is Private to the Microsoft Access Application. But I do similar things with Pop-Up forms. As mentioned, it is not easy. In order to make it, 'not clumsy', I use advanced programming techniques.

One point I would like to add, though, is that you do not have to make every Pop-Up form Modal. The Modal property does a very specific job.

[CJ_London]

the problem with popup on its own is that if your forms are set as overlapping, the popup can appear behind the form that called it. This does not happen if your forms are set as tabbed.

[ItsMe]

the problem with popup on its own is that if your forms are set as overlapping, the popup can appear behind the form that called it. This does not happen if your forms are set as tabbed.

Yeah, the transition to designing in Tabbed was not an easy one for me. I have been using tabbed, almost, exclusively. I tend to forget the nuances between the two. I think I prefer tabbed, from the User's perspective. However, I do not know that I miss writing all of those Docmd.Maximize statements.

[CJ_London]

I actually prefer overlapped, certainly for development - there are many occasions where you want to view say a table and a query or form side by side.

[MunroeM]

In circumstances like this I will employ unbound controls. Like June7 mentioned, bound controls will do stuff.

I won't belabor the point that the Master/Child Link properties are the public interface for a Black Box that is Private to the Microsoft Access Application. But I do similar things with Pop-Up forms. As mentioned, it is not easy. In order to make it, 'not clumsy', I use advanced programming techniques.

One point I would like to add, though, is that you do not have to make every Pop-Up form Modal. The Modal property does a very specific job.

Im trying to make the adding toolboards and adding toolboards with temmis items inside it a one page step. it does work but i know im going to get someone who likes to click everywhere and they are going to add a temmis item to a kit that they did not want to.

How can i make that popup only add temmis items to the board that they entered in the addtoolboard form

[ItsMe]

I don't know of a simple way to explain how I manage it. To oversimplify things, there are two ways to manage constraints. They can be managed at the table level or at the application level. An example of a constraint at the table level might be indexing a column and not allowing duplicates or not allowing a Null. An example of managing constraints at the application level would be using code to perform gated checks on User input. For instance, code would not allow a User to input plain text where a Date belongs.

Microsoft Access has many tools available to manage constraints and enforce referential integrity. I prefer to limit the number of built in tools I employ to a bare minimum. Instead, I use code to manage constraints and enforce referential integrity. I choose code because most of the applications I build are Line of Business type applications. The applications I build tend to be customized in a way that tools get in the way. In other words, tools provided by Rapid Application Development systems limit the amount of freedom and flexibility a developer has. It is a double edged sword.

In my applications, I do not allow Users to click on stuff that might violate constraints. To start, I do not allow Users to interact with the Ribbon, Back Stage, Options, Navigation Pane, Context Menu, Quick Access Toolbar, etc. Then, if they want to do something, it needs to be something specific and if they do not want to finish what they started, they need to Cancel.

To gain insight on how this sort of thing is accomplished via code, you might want to practice on an unbound form and unbound controls. I do not say this because I believe you should use unbound forms everywhere. I say this because I believe it is a good exercise that demonstrates how much Access depends on its intrinsic tools. Using an unbound form to perform Create Read Update Delete (CRUD) operations will flex your programming skills and may force you to recognize the difference between tools and code.

The entire thing has to be conceptualized as you develop. Without experience, this is impossible to do. With experience it is difficult to do. It is up to you, the developer, to determine where and how constraints are managed. In order to do this, you need a clear picture in your head of the overall scope of the project and the Business Rules. Then you need to abstract these ideas and translate the abstract ideas into code within a Module.

Understand the high level perspective. Break off a small piece and tackle it. Use your experience to understand the big picture. Use your experience to break off a small piece. Use your experience to implement an abstract idea. It will be a constant rotation of hitting on all of these points. Gain understanding, then fill that gap for experience, attempt implementation, rinse and repeat.

[June7]

I've never designed a db using Tabbed Documents, always Overlapping Windows. I also like to view objects side-by-side when developing.

How would someone unintentionally add a temmis to a kit with a form/subform arrangement? How would a popup/modal form prevent this?

[MunroeM]

I've never designed a db using Tabbed Documents, always Overlapping Windows. I also like to view objects side-by-side when developing.

How would someone unintentionally add a temmis to a kit with a form/subform arrangement? How would a popup/modal form prevent this?

When they click away from the sub form it would save the record if all required data was entered. I know i could have made it so if they click away it does not save the data and it would be cleared. But same applies if someone is entering a temmis item they want if they click away it clears the data they just entered.

[June7]

But how is that unintentional? User must first select or enter the appropriate kit on main form before entering dependent data in subform or opening popup. Either way, the issue is the same. User must be aware of what they are doing. No database can be totally 100% foolproof - there is always a better fool.

You can nag them with annoying validation popups - "Do you really want to add this temmis to this kit?" - and take action based on response.

[MunroeM]

Always a better fool... i like that

I've gone for a more simple design where they enter the tool board on one form and they enter the temmis items on another. I put a reminder that they need to enter the temmis items on a seperate form and gave them a link to it

[June7]

More simple is a matter of point of view. That will require code to pass the primary key to the popup form.