Search results

I don't like this idea for reasons I will explain in the post after the next (#51). But, this just gave me an idea that would have been a super simple solution... I don't want to rob the users of the possibility to see the report in preview. However, I could show the user a preview but at the...

In theory it could. In practice it makes very little sense because the customer supposed to sign the contract is physically there, in person, expecting to get a paper copy of the contract just signed.

I reply to this because that's the potential(!) flaw with your code suggested in #34. My gut feeling (haven't had time to evaluate) is that half a second is too long an interval to reliably catch a document in the print queue of a PDF printer. At the same time half a second might be shorter than...

Yikes! That's what this thread is all about. Now tell me how to detect printing from report preview. General info: I think my approach using the print spooler API is going to work. Unfortunately the client came along with a couple of other high priority tasks and I had to put this report...

This actually was the case as he referenced Late Binding indirectly by "You don't need a VBA reference.". This is also possible with .Net, but you must register the library you create to use events similar to the Winsock OCX.

Neither. I just wanted to elaborate on the difference of standard Windows controls and Access controls with regards to my suggestion. I expected the API approach to work at least while the control has the focus. Sadly, even this is not the case. I also quickly tried it now. My approach is very...

This is an example where @Albert D. Kallal's philosophy of Late Binding with his .Net loader is not the optimal solution because here events from the .Net component are an important part of efficiently integrating such an external component into an Access application. This is not a general .Net...

This is the essential difference in the context of my suggested solution. And most Access controls are only real windows with their own window handle while having the focus. Once they loose the focus they become just "pixels on the screen" without existing the Windows window hierarchy.

The data in the report is some sort of contract. As long as it wasn't printed, it is allowed that users or the application automatically make changes to the data. Once it is printed, changes are no longer allowed. I need to know when it is printed to mark the data as "printed". (Once they...

The Windows API way to achieve this would be to set a cue banner. I'm not sure if this works with an Access control that not currently has the focus. https://learn.microsoft.com/en-us/windows/win32/controls/em-setcuebanner

Sorry. That was a foreign language issue. I only noticed now that "is printed" is likely being read as "completed printing" while a literal translation to my language would be "is in the process of being printed". In theory you are right. The problem is that I need to know *when* to get the...

Indeed it would. It includes the comparatively easy part of fetching print job info from the print queue. I added something similar as a fallback because the print spooler events API function behave somewhat unpredictably in regards to the data the can be retrieved with their events. The...

I haven't. Your suggestion would probably solve the problem, but at what cost? Printing to PDF and displaying the PDF as preview will be much, much slower than just opening the report in preview, even if I use a webbrowser control to display the PDF instead of an external PDF viewer. Users will...

Actually, I don't understand how this suggestion could work. How would I sent an Access Report to a printer directly? Maybe the printer could be configured to bypass the print queue with the "Print directly to printer" option as shown in your screenshot. But this would mean to reconfigure all...

Thanks, I know that. It doesn't work with either of these two requirements: I've found a solution that also reliably works with a report displayed as dialog, but the "open preview, then print"-scenario is the tough nut I still try to crack.

@AHeyne , thank you for the suggestion. This would indeed be a possible solution to the problem as I presented it here. However, ... This, unfortunately, is the deal breaker here. The application is used at several distributed locations. Installing and maintaining an external service would add...

@The_Doc_Man , I also attentively read your previous longer post and mostly agree. I just reply to this short one because it covers the core items. It's not "or use API code", but one must use API code to do any of the former. I'm not interested in the completion of the print job, I just want...

The question I'm trying to get answered is not whether it printed OK, but whether the user sent it to the printer in the first place. Only if I knew that the user tried to print I could ask how it turned out. - But this is not my concern in this context. There currently are exactly these two...

@The_Doc_Man, this is a very good idea and one I consider for further investigation. I think, some of the stated reasons for your skepticism are not that big of a deal. There is a set of Windows API functions for interacting with printer spoolers. However, the apparently most suitable functions...

I want to know when a certain report is sent to a printer (as opposed to being displayed as preview). I.e., I want to be able to distinguish preview and printing in any of the reports Print events. This must also work if the report is displayed in preview before being sent to the printer and...