Good Day Mates, I have experience in MS Access but am stumped, maybe because MS Access just doesn't cut the mustard. In a nutshell, I am trying to build a Smart Report that does not need to be printed. Based on buttons clicked on the report, the report in REPORT VIEW (notice NOT Print Preview mode) and I want to HIDE or SHOW the Groupfooter based on the button clicks. Note: I am trying to avoid having numerous reports for each condition, just want a Smart Report to handle it.
Yes, Yes, Yes... I can make it work in PRINT PREVIEW using the Cancel command because the OnFormat event executes only in Print Preview mode.
Private Sub Groupfooter0_Format
If <condition> then
Cancel = True
End if
The OnPaint Event will NOT allow visibility commands to be set and gives an Error to that point, and the Cancel doesn't work either.
If <condition> Then
GroupFooter.Visible = True
Else
GroupFooter.Visible = False
End If
Again, I am hoping someone has experience with successfully hiding and showing groupfooters in REPORT VIEW using the OnPaint event and NOT the OnFormat event, because as explained, the user will control the report via buttons.
Cheers,
Related
I am using unbound endless forms to display data from my database.
The data source is set to queries which provide data to show on the form.
All tinkering with the data itself on the form is blocked (entry, adding, deleting, etc.).
The data on the form can, however, be filtered through Access' standard ways (right clicking on the data and selecting the options or through the navigation buttons down the bottom of the form).
I am using another unbound form as a menu. Buttons on the form let the user open the data display forms. The buttons are connected to the forms through an on- click event that triggers a DoCmd.OpenForm ("frmOutput") line of code to display the form.
Recently I've had users report, that opening the endless data display forms from the menu, filtering data on the form and then closing the form without taking the filter out has resulted in the form not being able to be opened again from the menu (clicking the respective button results in no action whatsoever). The bug seems to even save to the application somehow and moving the (frontend) file to another machine still shows the same error of not showing the form.
It seems that the bug appears more often when people use multiple screens, and use the application on their second screen (as per their Windows settings).
Does anybody know what causes the bug or how it can be prevented?
Any pointer in the right direction is much appreciated since I am at a loss where to even start looking for the culprit!
Hard to tell but it sounds like their filter is being saved when form is closed
If you already have an event that opens the form, try to just clear the filter property after it opens. You can do this from all your command buttons by just changing the form name that gets passed to it
Private Sub OpenUnfilteredForm(strFormName as String)
Dim frm As Form
DoCmd.OpenForm (strFormName)
DoEvents
If CurrentProject.AllForms(strFormName).IsLoaded Then
Set frm = Forms(strFormName)
With frm
.Filter = ""
.FilterOn = False
End With
End If
Set frm = Nothing
End Sub
I have a PowerPoint loaded with VBA and quite a few slides. I would like to be able to manually advance the slides by pressing the {Page Down} key when I am the user running the presentation, but, I want the {Page Down} key not to work when any other user is running the presentation.
I know the following:
I have a function that easily will return the name of the user, so, I can easily compare the current user to myself and execute code based on the match/lack of match. No problem here.
I know that I can set the presentation type by using: ActivePresentation.SlideShowSettings.ShowType = ppShowTypeSpeaker.
I know that I can set the way slides are advanced by using: ActivePresentation.SlideShowSettings.AdvanceMode = ppSlideShowManualAdvance
The problem and things I've tried:
Once the PowerPoint has started, using VBA code to change the value of ShowType from the default setting of ppShowTypeKiosk to ppShowTypeSpeaker does not seem to change the way the rest of the show functions.
Once the PowerPoint has started, using VBA code to change the value of AdvanceMode to ppSlideShowManualAdvance does not actually enable me to manually advance slides (I am still only able to advance slides using the ActiveX buttons on the slide).
I have thought about using event handling to capture the SlideShowBegin event, but, apparently events can only be trapped once code has established the link to the Application object, and, making that link has to happen in code that runs by clicking an ActiveX control (or similar user action) in an already-running slideshow so I am baffled how the SlideShowBegin event would ever be trapped without an AddIn with an Auto_Open macro.
Bottom line: Is there a way for PowerPoint VBA code to switch a slideshow from kiosk to speaker mode so that slides can be manually advanced? (Or, some other way to enable me to manually advance slides while preventing all other users from manually advancing slides?)
Thanks to #SteveRindsberg, the fix is to (a) determine whether or not to switch presentation modes, then, (b) if a switch is needed, run the code to change the settings, then, (c) programmatically end the slideshow, then, (d) programmatically run the code to re-start the slideshow.
It is assumed that the PowerPoint has been saved to run in Kiosk mode by default so that the standard user cannot use PageDown or other navigation techniques to move through slides; that is, slides can only be navigated by the programmer's ActiveX controls that use VBA code to move through the slideshow. (This is handy for quiz-type slideshows, etc.)
Specifically, I have Slide 1 which includes an ActiveX [OK] button on it which the user is directed to click in order to continue; basically, Slide 1 is a title slide that gives the name of the PowerPoint. When the OK button is clicked, the code behind the [OK] button checks to see whether the user should be allowed to change the presentation mode from the default Kiosk mode to Speaker mode. Here's the code behind the [OK] button in Slide 1:
Private Sub cmdFeedbackOK_Click()
'handle the click of the OK button on the feedback which will move to the next slide or exit if the wrong OS or Office Version (based on text associated with the [OK] button
'check for superuser
If LCase(Environ("UserName")) = "{Windows username who is a superuser}" And ActivePresentation.SlideShowSettings.ShowType <> ppShowTypeSpeaker Then 'this will check to be sure that we have not already changed the ShowType (which will have changed if the user opts to switch modes and the PPTX has re-started)
'superuser, so, change to Speaker mode
If MsgBox("Do you want to switch to Speaker view instead of Kiosk view so you can use PageDown?", vbYesNo + vbDefaultButton1, "Use PageDown?") = vbYes Then
ActivePresentation.SlideShowSettings.ShowType = ppShowTypeSpeaker 'switch from Kiosk to Speaker mode so that PageDown key will work
ActivePresentation.SlideShowSettings.AdvanceMode = ppSlideShowManualAdvance 'switch to allow PageDown to manually advance the slides
ActivePresentation.SlideShowWindow.View.Exit 'exit the show because the change in play mode and advance mode will not take effect until the show is started again
ActivePresentation.SlideShowSettings.Run 'restart the show; code in the OnSlideShowPageChange will get triggered to skip this first slide if the user has restarted the show
Exit Sub
End If
End If
ActivePresentation.SlideShowWindow.View.Next 'move to next slide
End Sub
Then, to prevent the superuser from having to view the first slide twice when the slideshow re-starts, I have added the following code to the OnSlideShowPageChange event:
SlideName = ActivePresentation.SlideShowWindow.View.Slide.Name
If SlideName = "sldTitle" Then 'we're on the first slide
If ActivePresentation.SlideShowSettings.ShowType = ppShowTypeSpeaker Then 'this will be true if the Windows user is me (see code in Slide1), and, since I've already seen that slide, just go to the next slide
ActivePresentation.SlideShowWindow.View.Next 'skip the first slide for superuser
'execute other code as desired
'use Exit Sub here if the code below does not need to run for the superuser
End If
End If
'execute other code as desired here, e.g., code for standard users
For me, Slide 1 gives a lengthy delay (maybe 10 seconds) after clicking the [OK] button before the slideshow re-starts, but, the standard user does not experience the delay so I don't mind the wait--it probably has something to do with the VBA code and large number of slides in the presentation that have numerous ActiveX controls--at least, that's my guess.
Hope this helps someone out!
I am trying to put an animated loading gif on a form during a long subroutine execution (specifically, sub being fired on a form's button click event), and it turns out to be surprisingly difficult in MS Access.
I already have my gif animation put on the form, linked to ActiveX Web Browser control (call it loadingGif in example below). It turns out, that doing simply:
Private Sub someButton_Click()
loadingGif.Visible = True
'... hard stuff here ...
loadingGif.Visible = False
End Sub
fails because screen doesn't get refreshed during subroutine execution, and so the user never sees the loadingGif control. Is there any way to make it visible during single subroutine execution?
Also:
I know it is possible to create an animated modal pop-up form instead, but that's not the idea
I already also use Hourglass, but icon on a form seems much more appealing
Is there any way to test if an event linked to a control is triggered by the program, rather than by user action?
I have a scroll bar which fires events when the user moves it. I want to be able to move the scroll bar programmatically elsewhere in the code without sending these events. i.e. events should only fire when the user interacts with the control, not when I move the control via code.
I also have radio buttons and numeric up/down controls I'd like to b able to do this with.
Thanks
There maybe better ways to do this but a quick way would be to use a boolean variable that you set when you are programmatically scrolling and unset it when you're done. Then in your event check that before executing the logic.
If IsProgramaticScrolling = False Then
' Do whatever it's supposed to do when your program isn't
' scrolling via code.
End If
I have a form in a vb.net windows form application called PolicyRefreshStatus.vb that has a ProgressBar control on it. From the main form called EditPolicy.vb I need to show PolicyRefreshStatus.vb over top of EditPolicy.vb - but the way things are wired I'm controlling the the ProgressBar and it's steps from logic inside EditPolicy.vb.
If I display the PolicyRefreshStatus.vb bar using the .show() method things work fine. The problem is if the user clicks back on the main form then PolicyRefreshStatus.vb losses focus. If I show PolicyRefreshStatus.vb as a modal form using .ShowDialog() then execution halts in EditPolicy.vb after the .ShowDialog() statement.
so for example in the code:
mPolicyRefreshStatus = New PolicyRefreshStatus
mPolicyRefreshStatus.pbMax = mPolicy.ClaimsUpdateMax
mPolicyRefreshStatus.ShowDialog()
mPolicy.UpdateFromFIS()
The line mPolicy.UpdateFromFIS() never executes because it's waiting for the PolicyRefreshStatus form to close.
How can I show PolicyRefreshStatus in a modal form but let execution continue in EditPolicy.vb?
You've got a couple of related options.
This first is to pass the unit of work to the progress bar in the form of a delegate or a class implementing an Interface. Something like this (not checked for correctness, just a rough example):
mPolicyRefreshStatus = New PolicyRefreshStatus
mPolicyRefreshStatus.pbMax = mPolicy.ClaimsUpdateMax
mPolicyRefreshStatus.UnitOfWork = AddressOf(mPolicy.UpdateFromFIS())
mPolicyRefreshStatus.ShowDialog()
Then within the progress form you can call back to the routine that actually does the work.
Another approach is to define events on your ProgressForm and then the owning/launching object can handle those events to do the work in. With this option you can create a fairly detailed set of events to be able to handle incremental work or cancels, but the concept is the same, youu are calling back from the progress form into launcher to perform the actual business logic.
You cannot show the form modally and let your routine continue. You must show the form Non-modally and then do your other stuff, closing the form when you've finished. Maybe a loop until the task has finished?
Using Show() with a parent form parameter will give you better usability. More like a tool window.