Solved it's Magic you can store data in a closed unbound form!

[Uncle Gizmo]

I am challenging you to solve this puzzle

Cool! I like a challenge!

Here's one for you, open a form with a combobox on it. And in the process of opening, have the combo open up ready for the user to make a selection....

 

[isladogs]

Solution thanks to MajP, who is much more experienced then I am. If you type Form_FormName.TxtTest = "Hallo" into the immediate window, this will open (apearantly) a Hidden instance of the form. When you open the form from the nav pane, another instance (..may be not the correct word, don't kill me please..) of the form is opened. Type Form_FormName.visible = True and you will see two times the same form. Like with a real magician, the magic wasn't realy magic. I still think you can use this to store Public variables, with a bound form they will be still there after closing the database. But i didn't test this yet..

I'm bemused by this thread and disagree with the comments above so I tested for myself on an unbound form in Access 365:

1. To check that the form is closed initially, I first typed ?CurrentProject.AllForms ("Form1").IsLoaded in the immediate window. It returned False
2. Next I typed Form_Form1.txt1="Hello" in the immediate window followed by ?CurrentProject.AllForms ("Form1").IsLoaded again which now returns True.
In other words, entering 'data' as shown loads the form. It does not appear to open the form hidden.
2. Finally, I typed Form_Form1.Visible=True => ONE copy of the form opens

Leaving aside the fact that unbound forms are of limited use, that 'data' is of course lost when the form is closed and reopened.
So you cannot use this to store public variables even whilst the database is open ... let alone when the database is closed & reopened.

So does it have any practical use? Not as far as I can tell

Cool! I like a challenge!

Here's one for you, open a form with a combobox on it. And in the process of opening, have the combo open up ready for the user to make a selection....

Much too easy!

Or try this. Its a puzzle where the answer is supplied - in this case I'd like an explanation of why it works:

A Complex Deep Hidden Attachment Mystery

This is the fifth in a series of security challenges. In this case, a problem occurs when deep hiding attachment fields and a solution is provided. But why does the solution work?

www.isladogs.co.uk

 

[Gasman]

Much too easy!

For you maybe. I tried various implementations of what I could find via Google and it did not work for me.
Not sure if I am missing setting a property, but none appear to have been mentioned in those links.
Combo is unbound as well, as was just for a test.

 

[isladogs]

In Form_Load, type Me.ComboName.Dropdown

 

[Gasman]

Well I actually tried that first.
Then I got an error message saying control needs the focus, so I set focus, still did not dropdown.
Then I put the dropdown in the setfocus event and set focus from the form load, still did not work.

Was looking to add Sendkeys Enter, and then had to get onto something else.

Even tried Application.Screen.ActiveControl.Dropdown
That gives me the following error

 

[isladogs]

I was out walking the dogs earlier when I replied in post #24 and forgot about needing to set focus
Attached is an example using 5 cascading combos each of which drops down when it receives focus.
Click the OK button to start

 

[Gasman]

That works for me?
So what is wrong with the attached?
Only one form in there ATM

 

[MsAccessNL]

I'm bemused by this thread and disagree with the comments above so I tested for myself on an unbound form in Access 365:

1. To check that the form is closed initially, I first typed ?CurrentProject.AllForms ("Form1").IsLoaded in the immediate window. It returned False
2. Next I typed Form_Form1.txt1="Hello" in the immediate window followed by ?CurrentProject.AllForms ("Form1").IsLoaded again which now returns True.
In other words, entering 'data' as shown loads the form. It does not appear to open the form hidden.
2. Finally, I typed Form_Form1.Visible=True => ONE copy of the form opens

Leaving aside the fact that unbound forms are of limited use, that 'data' is of course lost when the form is closed and reopened.
So you cannot use this to store public variables even whilst the database is open ... let alone when the database is closed & reopened.

So does it have any practical use? Not as far as I can tell


Much too easy!

Or try this. Its a puzzle where the answer is supplied - in this case I'd like an explanation of why it works:

A Complex Deep Hidden Attachment Mystery

This is the fifth in a series of security challenges. In this case, a problem occurs when deep hiding attachment fields and a solution is provided. But why does the solution work?

www.isladogs.co.uk

Can you explain point 2, ...loads the form, it does not appear to open the form hidden.. What's the difference between a loaded form (but not showing) and a hidden form?

As long as the form is Loaded/Hidden you can access the data and other properties, , just by one line Form_Form1.controlname and if you make the form bound, the data is still availabe after closing the database. I have seen posts about storing Public variables in a form. This way you can do it by just one line of code. Also opening a hidden form can be done by this line, or what about replacing openargs with:

I see a lot of possibilties, but it's quite possible that i am not experienced enough to oversee the problems, so any advice is welcome.

Opening a Form instead of using docmd with openargs:

Form_Form1.txt1 = "Daniel"
From_Form1.visible = True

Another question, I noticed if the form is already open as a subform, it seems te reference to this subform. Form_Form1.txt1 seems to work instead of Forms!F_Main.SubContainer.Form.txt1 . I used it in a recent application and so far no problems. You also get intellisense this way, Am i missing/overseeing something here?

Thnx.

 

[isladogs]

That works for me?
So what is wrong with the attached?
Only one form in there ATM

Its working now. Slightly more complicated than my answer written in #24 done when away from the computer.

You need another control to initially have focus before transferring the focus to the combo.
So I added a text box and used the Form_Timer event to create a slight delay before this was done

It seems that using Form_Load event for this doesn't work - Access treats it as though it already had focus so ignore subsequent code

The combo dropdown code needs to be in the combo got focus event

Private Sub Form_Timer()
    Me.Combo0.SetFocus
    DoEvents
    Me.TimerInterval = 0
End Sub

Private Sub Combo0_GotFocus()
  Me.Combo0.Dropdown
End Sub

 

[Uncle Gizmo]

I don't agree with the use of the timer event as I was taught many years ago that using the timer was asking for trouble.

The way I would do this is posted in a sample file in this thread, see here:-

Why Doesn't the Dropdown sustain?​

Why Doesn't the Dropdown sustain?

Private Sub Form_Open(Cancel As Integer) With Me .Recordset.AddNew End With End Sub Private Sub Spare_GotFocus() Spare.Dropdown End Sub The combo wraps-up after the Open Sub Ends... :banghead:

www.access-programmers.co.uk

 

[isladogs]

I don't agree with the use of the timer event as I was taught many years ago that using the timer was asking for trouble.

Really? So were you taught why it was asking for trouble?

The requirement is to create a delay after the form loads. Any method that achieves that will work

 

[isladogs]

Can you explain point 2, ...loads the form, it does not appear to open the form hidden.. What's the difference between a loaded form (but not showing) and a hidden form?

I stressed the 'not appear to ...' I think its just loaded into memory rather opened hidden ...but I may be wrong
Either way, only ONE instance of the form appears when made visible ...NOT two.
If you then open another instance of the form whilst the first is open, the textbox is blank (as it is an unbound form)

It is impossible to store data in an unbound form after it is closed - forms do not store data

As long as the form is Loaded/Hidden you can access the data and other properties, , just by one line Form_Form1.controlname and if you make the form bound, the data is still availabe after closing the database. I have seen posts about storing Public variables in a form. This way you can do it by just one line of code.

I can't get it to work at all with a bound form. Error 424 - object required
So I can't set the value in the first place let alone keep the data after closing the database
In any case, if there is more than one record, you would have no method of specifying which record should be affected

Also opening a hidden form can be done by this line, or what about replacing openargs with:

I see a lot of possibilties, but it's quite possible that i am not experienced enough to oversee the problems, so any advice is welcome.

Opening a Form instead of using docmd with openargs:

Form_Form1.txt1 = "Daniel"
From_Form1.visible = True

Even if any of this works for you, I can't see how it is better than standard approaches

Another question, I noticed if the form is already open as a subform, it seems te reference to this subform. Form_Form1.txt1 seems to work instead of Forms!F_Main.SubContainer.Form.txt1 . I used it in a recent application and so far no problems. You also get intellisense this way, Am i missing/overseeing something here?

I didn't test that

So far none of the experienced developers who have replied have agreed with your analysis.
If you are convinced you are on to something that we are unable to visualise, I suggest you create an example database to illustrate this approach in practice.

 

[MsAccessNL]

It

I stressed the 'not appear to ...' I think its just loaded into memory rather opened hidden ...but I may be wrong
Either way, only ONE instance of the form appears when made visible ...NOT two.
If you then open another instance of the form whilst the first is open, the textbox is blank (as it is an unbound form)

It is impossible to store data in an unbound form after it is closed - forms do not store data




I can't get it to work at all with a bound form. Error 424 - object required
So I can't set the value in the first place let alone keep the data after closing the database
In any case, if there is more than one record, you would have no method of specifying which record should be affected



Even if any of this works for you, I can't see how it is better than standard approaches



I didn't test that

So far none of the experienced developers who have replied have agreed with your analysis.
If you are convinced you are on to something that we are unable to visualise, I suggest you create an example database to illustrate this approach in practice.

 

[MsAccessNL]

I really don’t know hiw to reply. I didn’t want to attack anybody. You, and others are much more experienced the I am, Yes that’s correcr. My thoughts about the analysis was wrong, yes. If you take a deep breath and look at my questions again tomorrow, you will interpret them may be different. I apologize to everyone about my post and I will choose my words more careful in the future. If this forum is meant for specialists only and my posts aren’t welcome, please tell me.

I already posted solved after the first negative reactions, Tell me what i can do so everyone sleeps well tonight.

 

[isladogs]

I hope my comments weren't seen as a personal attack as that wasn't my intention.
I've been using Access for over 25 years but there is still much I don't know and on many occasions I've learned things from new users.
I think English isn't your first language and that may explain the use of some vague or incorrect terminology.
If you look back through this thread, several of us have explained points imprecisely, probably including me.

This forum is meant for users of all abilities. It is just that in this case, it attracted several very experienced members trying to clarify meanings and genuinely interested in whether this really was a new feature that we weren't aware of.
Indeed, that was why I suggested you created an example database ...in case you are onto something unexpected.

For info, I hadn't noticed you'd marked it solved as I just read the latest posts added since my last view

Please don't be discouraged from posting in this forum

 

[Uncle Gizmo]

It is impossible to store data in an unbound form after it is closed - forms do not store data

It is possible to store data in a form. All you need to do is add a custom property to the form. I use the ability to store data in a "Form Custom Property" to create a "Sticky Form" that's a form where once you've moved it to a particular location the form will stick to that location. You can see it in action in this YouTube video:-

Nifty Sticky Form - Quick Demo​

The code is readily available on the internet:-

Creating Using Form Custom Property

Learn Advanced Microsoft Access Programming Techniques, Tips and Tricks

www.msaccesstips.com

I have used this code in a sample database. With this Example you can create your own sticky forms easily. See this video here:-

Nifty Sticky Form - Setup​

"Sticky Form" creation software available here:- https://niftyaccess.gumroad.com/l/StickyForm - Get it for free with coupon code:- freeORbuyUncleAcoFFee

It is also possible to add custom properties to the actual database file itself, the mdb the accdb and also mde and accde versions of a database I demonstrate this in a Nifty product "Custom Database Property" here:- https://niftyaccess.gumroad.com/l/custDBProp

You can add things like:-

• CopyRight Notice
• Author/Programmer Name
• dB Version
• Languages
• Serial Numbers
• Last saved Date
• User Name

The code is available for Free HERE:-

Custom Database Properties

Access/VBA Tutorials - Custom Database Properties

Tutorial: Custom Database Properties. If you want to store custom data in your database without exposing it through the Access interface, use this neat method.

www.everythingaccess.com

 

[The_Doc_Man]

It has been suggested by one of the participants of the thread that this argument has headed towards toxicity. In my capacity as moderator, I am going to unilaterally close this thread for a while. Cool off, people.

@MsAccessNL - If you originally misinterpreted something, it is not such a terrible thing. If someone corrected you about that misinterpretation, it might turn into a learning experience. In terms of the toxicity that has suddenly developed, I hope I can assure you that you are not to blame for the turn this has taken. We have a case where some experts rubbed a little harder than they needed to and struck sparks. Your beliefs (erroneous or not) are not to blame.

Taking off the moderator hat:

For the record, there are only a couple of ways to store data in an actual Access database past closing. It has to be either in a table or in a stored object (think OLE) or in a property of some object or a sneaky update of a VBA module's text to include something hidden in stored instruction lines including stored comment lines. No other part of Access program memory persists across activations.

The "pure" code (the Access main code including the GUI, VBA driver, and JET/ACE) CANNOT store anything. Those program segments are not writeable. The "impure" code (per-instance data) is mostly recreated from empty pages (see Windows Free Page List) at each launch. If the impure segment starts life non-blank, it is COPIED from a non-writeable area into empty pages. Only data objects (tables, OLE objects) or GUI objects stored in the FE or BE file - objects that have properties - can store data. The controls AS CONTROLS do not store data when closed. Only their properties can persist - if you saved them in Design mode. This statement comes from a consideration of the way Windows images (such as MSACCESS.EXE) are built and a knowledge of program internal structure for Windows programs in general.

 

[The_Doc_Man]

I have unlocked the thread after hiding the posts containing the argument. Guys & gals, if you have dirty laundry to air out, use profile messages to drag each other over the coals. The thread contains some (I think) valuable discussions and, for the most part, was reasonable until the donneybrook started. If you would treat this forum a litte closer to being a family-friendly area, we might avoid more arguments.

@Jon, if you think I'm overstepping here, please advise - privately OR publicly, makes no difference.

 

[Jon]

@Jon, if you think I'm overstepping here, please advise - privately OR publicly, makes no difference.

I did not see the discussion, but I trust your judgement.