UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
2 Pages V < 1 2  (Go to first unread post)
   Reply to this topicStart new topic
> Boolean Getting Mysteriously Flipped, Access 2016    
 
   
fizzy1
post Nov 15 2019, 12:32 PM
Post#21



Posts: 546
Joined: 26-May 11



GPG,

QUOTE
It occurs to me that maybe a bit more background on the lifetime of variables might be helpful.

Placing this line in a form module only tells Access, "Here's the name of a variable you can use from time to time. No need to specify that name over and over."

Dim boolFormIsLocked As Boolean

That means the lifetime of the variable is the duration of an event fired within that form.

Placing this line in a separate module tells Access, "Here's the name of a variable you can use from time to time. No need to specify that name over and over. Also, once you give that variable a value, it'll stay that way until another event changes it later on"

Public boolFormIsLocked As Boolean

That means the lifetime of the variable is the duration of the current Access session in which this variable is initialized by opening the accdb.


Good info, thanks. I use that method already for global vbles -- I have a bunch that get set on start-up, and more than get utilized through the life of the session. Why I didn't do that in this case is that I have other forms that use the same method to lock and unlock, so I'd need a public vble for each form because I couldn't use the same vble as there would be cross talk. Hence I put it inside the form in question so that it was private to that, and lived only as long as the form.

Would this be a good use case for TempVars? I've not used them before but read up about them a while ago when I considered refactoring my slew of global public vbles.

However, your description doesn't, at least to me, explain why the vble reverts to its correct value in the GotFocus event. As I read your logic above, the vble should stay false in both the OnEnter and GotFocus events because it's been reset. But seemingly it hasn't.

--------------------

thanks,
fizzy1.
Go to the top of the page
 
projecttoday
post Nov 15 2019, 12:38 PM
Post#22


UtterAccess VIP
Posts: 11,289
Joined: 10-February 04
From: South Charleston, WV


Programming can throw you a red herring now and then!

--------------------
Robert Crouser
Go to the top of the page
 
GroverParkGeorge
post Nov 15 2019, 12:40 PM
Post#23


UA Admin
Posts: 36,193
Joined: 20-June 02
From: Newcastle, WA


Tempvars avoid the problem, yes.

It's worth further review.


--------------------
My Real Name Is George. Grover Park Consulting is where I did business for 20 years.
How to Ask a Good Question
Beginning SQL Server
Go to the top of the page
 
fizzy1
post Nov 15 2019, 02:28 PM
Post#24



Posts: 546
Joined: 26-May 11



Good info, thanks. So it sounds like I'm hearing that the boolean lost scope / died and has thus reverted back to False by the time we get to the OnEnter event.

But that doesn't explain how it somehow gets "resuscitated" and comes back to life as a True when in the GotFocus event. At that point if it's out of scope then the GotFocus event should have no knowledge of what it used to be, but just see it as False. Yet it does not.

How does that happen?

--------------------

thanks,
fizzy1.
Go to the top of the page
 
cheekybuddha
post Nov 15 2019, 02:44 PM
Post#25


UtterAccess Moderator
Posts: 11,909
Joined: 6-December 03
From: Telegraph Hill


I just looked at your db.

It's too weird!

I don't think any of the explanations above really explain what is happening.

At first I thought maybe each row change was technically going to a new form (Continuous forms, are effectively a single form detail repeated over), but you still get the same effect moving from control to control on the same row.

It's as if behind the scenes the form is re-created on each new cell selection.

George has given a solution, but I don't understand why it doesn't work with a variable declared within the form's own class module. shrug.gif

d

--------------------


Regards,

David Marten
Go to the top of the page
 
fizzy1
post Nov 15 2019, 03:08 PM
Post#26



Posts: 546
Joined: 26-May 11



QUOTE
I just looked at your db. It's too weird!

Thank you, I was kinda losing my mind trying to get this otherwise simple thing to work properly.

Certainly I can do as GPG suggests, I've done it before, but in this particular use case it's not very clean. TempVars might work better. Either way, this system should just work as I have it, though, at least I think it should.

Access bug?

--------------------

thanks,
fizzy1.
Go to the top of the page
 
tina t
post Nov 15 2019, 03:27 PM
Post#27



Posts: 6,183
Joined: 11-November 10
From: SoCal, USA


fizzy, i wonder if there is a corruption issue, either at the form or db level? have you tried rebuilding the form? importing all, or at least relevant, objects into a new blank db? decompiled/recompiled your current db?

hth
tina

--------------------
"the wheel never stops turning"
Go to the top of the page
 
fizzy1
post Nov 15 2019, 03:32 PM
Post#28



Posts: 546
Joined: 26-May 11



Tina,

No corruption. See post a few above where I re-created a basic db from scratch that reproduces the action.

--------------------

thanks,
fizzy1.
Go to the top of the page
 
isladogs
post Nov 15 2019, 05:51 PM
Post#29


UtterAccess VIP
Posts: 1,895
Joined: 4-June 18
From: Somerset, UK


This won't by itself solve your problem but it will make your form easier to use.
Scrap the cmdLockform button - or at least for now disable it & hide it.

Change the code for cmdUnlockForm button as follows so it acts like a toggle button:

CODE
Private Sub cmdUnlockForm_Click()
On Error GoTo Error_Proc

     If Me.cmdUnlockForm.Caption = "Lock" Then
        Me.HeaderCaptionLabel.Caption = "Locked"
        Me.cmdUnlockForm.Caption = "Unlock"
        boolFormIsLocked = True
        Debug.Print "Form_" & Me.Name & ".cmdUnlockForm_Click: boolFormIsLocked = " & boolFormIsLocked
    Else
        Me.cmdUnlockForm.Caption = "Lock"
        Me.HeaderCaptionLabel.Caption = "Unlocked"
        boolFormIsLocked = False
        Debug.Print "Form_" & Me.Name & ".cmdUnlockForm_Click: boolFormIsLocked = " & boolFormIsLocked
    End If

Exit_Proc:
  '  On Error GoTo 0 'remove this
    Exit Sub
Error_Proc:
    MsgBox "Error " & Err.Number & " (" & Err.Description & ") in procedure cmdUnlockForm_Click of " & Me.Name, vbInformation, Application.Name
    Resume Exit_Proc
  '  Resume 'remove this as well
End Sub


I believe you should also remove the line On Error GoTo 0 from the Exit_Proc of ALL procedures as it does nothing in an exit event
Similarly remove the final line Resume from the Error_Proc part of each procedure as it will never run
Both of those lines are inappropriate

I'm tempted to suggest you just stop recording the boolFormIsLocked status on the OnEnter vent but I doubt you'd be satisfied with that

--------------------
Colin (Mendip Data Systems)
Website, email
Go to the top of the page
 
fizzy1
post Nov 15 2019, 07:52 PM
Post#30



Posts: 546
Joined: 26-May 11



Colin,

A few things...

1. Thanks for the pointers on the error handler -- I'm reusing someone else's. I think the final Resume is in there for debugging to just drag the pointer to it and hitting Play.

2. What do you mean by "stop recording the boolFormIsLocked status"? Do you mean the many debug.Print messages? If so, they're just there for debugging so I can see what's happening. I remove them once the feature is working properly.

3. In the code you provided, do you actually mean this:

Else
Me.cmdUnlockForm.Caption = "UnLock"
?

Thanks,
Toby.

--------------------

thanks,
fizzy1.
Go to the top of the page
 
isladogs
post Nov 16 2019, 04:02 AM
Post#31


UtterAccess VIP
Posts: 1,895
Joined: 4-June 18
From: Somerset, UK


Hi Toby

1. Both the lines I mentioned are superfluous and should be removed

2. I realise that the debug lines are only there for testing
However, as the controls get focus as soon as you enter them, it seems to me that only the get focus boolean value has any real meaning.
The On Enter value can therefore be ignored (whatever the reason that it happens)

3. The code I supplied was EXACTLY what I meant. See modified database attached
Its an approach I often use to allow command buttons (or labels) to fulfil two or more 'roles'
In this case effectively act as a Lock / Unlock toggle button.
Of course you could also use an unbound checkbox for this purpose

Attached File(s)
Attached File  split_form_boolean_flipping_test_v2.zip ( 29.48K )Number of downloads: 2
 

--------------------
Colin (Mendip Data Systems)
Website, email
Go to the top of the page
 
cheekybuddha
post Nov 16 2019, 03:20 PM
Post#32


UtterAccess Moderator
Posts: 11,909
Joined: 6-December 03
From: Telegraph Hill


The issue is caused by the use of the split form.

If you change to a continuous form the symptoms do not occur.

IIRC, from reading other topics on UA, split forms seem to cause a lot of grief. I have never really used them.

I think we can add this as another split form gotchya!


--------------------


Regards,

David Marten
Go to the top of the page
 
isladogs
post Nov 16 2019, 03:35 PM
Post#33


UtterAccess VIP
Posts: 1,895
Joined: 4-June 18
From: Somerset, UK


Well spotted David. I hadn't even noticed it was a split form and frankly there's no reason to use one in this case.

I also avoid split forms (and for that matter navigation forms).
In each case the peculiarities of the forms often cause coding issues.

In case its of interest, a couple of years ago I developed an emulated split form (ESF) with assistance from several other developers
This has all the advantages of the MS split form but without the disadvantages. See Emulated Split Form

--------------------
Colin (Mendip Data Systems)
Website, email
Go to the top of the page
 
cheekybuddha
post Nov 16 2019, 04:52 PM
Post#34


UtterAccess Moderator
Posts: 11,909
Joined: 6-December 03
From: Telegraph Hill


>> I hadn't even noticed it was a split form <<

I too hadn't noticed, but the name of the attachment in your Post#31 caused me to investigate!
QUOTE
split_form_boolean_flipping_test_v2.zip


(I missed it when D/L'ing Toby's original db!)

--------------------


Regards,

David Marten
Go to the top of the page
 
isladogs
post Nov 16 2019, 05:11 PM
Post#35


UtterAccess VIP
Posts: 1,895
Joined: 4-June 18
From: Somerset, UK


Obvious really...with hindsight!

--------------------
Colin (Mendip Data Systems)
Website, email
Go to the top of the page
 
fizzy1
post Nov 18 2019, 03:20 PM
Post#36



Posts: 546
Joined: 26-May 11



Quick comment from the OP... I've only recently moved to 2016 for development (from 2010) and discovered split forms. Frankly they just seem easier than a regular form that then contains a datasheet subform. Seems like a win to me. However, if they're buggy...

I did see a couple of comments here about people avoiding split forms. I'm not a pro, so could you give me a few points on why not to use them?

--------------------

thanks,
fizzy1.
Go to the top of the page
 
theDBguy
post Nov 18 2019, 03:46 PM
Post#37


UA Moderator
Posts: 76,880
Joined: 19-June 07
From: SunnySandyEggo


Hi. Just one person's humble opinion... I don't avoid Split Forms, and I do use them.

--------------------
Just my 2 cents... "And if I claim to be a wise man, it surely means that I don't know" - Kansas
Access Website | Access Blog | Email
Go to the top of the page
 
isladogs
post Nov 18 2019, 06:25 PM
Post#38


UtterAccess VIP
Posts: 1,895
Joined: 4-June 18
From: Somerset, UK


I do avoid them as they can be difficult to modify to any significant extent from the MS supplied form.
In fact a couple of years ago I worked on an emulated split form (ESF) which has all the advantages but without the disadvantages.
The emulated version is more flexible and easier to code.
If you want to investigate it, see http://www.mendipdatasystems.co.UK/emulate...form/4594398119

--------------------
Colin (Mendip Data Systems)
Website, email
Go to the top of the page
 
2 Pages V < 1 2


Custom Search


RSSSearch   Top   Lo-Fi    11th December 2019 - 07:40 PM