PSet problem

Obviously, we need more information.
Can you post your code?

Also what is the purpose for needing Pset?
    "set a start point."
What does this mean?
Start point for what?
For what purpose?

Perhaps there is an easier way to do what you are looking for...

JeffCoachman

Hi Jef

My questions ramble on a bit so I am trying to be more concise.

The start point can be for a simple drawing of a box.
When I draw the box I want to go to another point to draw another box. So why not just start a new box. well the code is incremental so if I want to draw the box 4 times I want the code to repeat every 50 mm say. All i need do is a do while thingy and I get 4 boxes. But at every start point where I state:
Me.PSet Step(100, 0) I get a 2mm long line on my report.

But all I want to know is why do I get this line at all

Here is the code:
Private Sub Detail_Format(Cancel As Integer, FormatCount As Integer)
Me.PSet Step(100, 100)
Me.Line Step(0, 0)-Step(100, 100), 0, B
End Sub
Capture.JPG

Not sure,...when I use your code, I just get a box...

FWIW,

Most Access developers will shy away from creating objects "on the fly"
(Note that the boxes will not appear if the report is opened in "Report View", because OnFormat code will not run)

Why not create the max number of boxes, ...then just use code to hide/show them...

So I am still unclear of the need here...

JeffCoachman

Dumb question:
Does it actually PRINT the line.
The print preview of a report and it's actual rendering on paper, for all that they are touted to be WYSIWYG, sometimes are not.

Pset can be used to draw lines though.  From the Access 2003 help

Example
The following example uses the PSet method to draw a line through the horizontal axis of a report.

To try this example in Microsoft Access, create a new report. Set the OnPrint property of the Detail section to [Event Procedure]. Enter the following code in the report's module, then switch to Print Preview.

Sub Detail_Print(Cancel As Integer, PrintCount As Integer)
    Dim sngMidPt As Single, intI As Integer
    ' Set scale to pixels.
    Me.ScaleMode = 3
    ' Calculate midpoint.
    sngMidPt = Me.ScaleHeight / 2
    ' Loop to draw line down horizontal axis pixel by pixel.
    For intI = 1 To Me.ScaleWidth
        Me.PSet(intI, sngMidPt)
    Next intI
End Sub

Give that PSet is meant to be used so:

PSet Method
The PSet method sets a point on a Report object to a specified color when the Print event occurs.
expression.PSet(flags, X, Y, color)

and the help states
It's faster to draw a line by using the Line method rather than the PSet method.
I am not sure why you are using PSet.

It does not print but looks pretty weird on screen. I am using PSet to move the start point on from one place to another. The reason is so that when I run the code it will give me a number of boxes See attached. But all boxes are variable as in the drawing
Capture.JPG
Capture1.JPG

To me it just looks like and odd apparition of your looping.
Again, ...when I used your code to draw one box, ...the box looks OK.

To me, this should really be an "Image", or a rendering generated by a CAD program.
So I am not quite sure why you need to generate complex objects like this on the fly, ...and in Access.

This looks like a Mechanical drawing or Spec sheet of some type, so again, typically these types of "drawings" are done in a CAD program, ...not in your database program.

Doing this in Access may be more trouble than it is worth. Rectangles are one thing, ...but what happens when the shapes are more complex?
Doing these types of things in Access require a lot of processing power.

So while you may find the hitch in your code that causes this issue, ...IMHO, Access is not the best choice to do things like this.
Creating "Specification Drawings" is something that should be done in the Drafting department, ...and not forced upon the "Database Developer".

JeffCoachman

Hi Jef

I was told to use cAD 10 years ago. Not sure how I would get 10 or even 200 cad drawings in a report like the one that access produces. See PDF

I would be interested in seeing a CAD package that works with Data from Access do you know of any
TotalProject.pdf

Hi Jef

Did you say that you do not get the problem on the report? I do not get it on Print but the report looks strange. Access 2002

Not sure how I would get 10 or even 200 cad drawings in a report like the one that access produces. See PDF

Not sure why this is being designed as a "Report", instead of multiple "drawings"

So are you saying that your compnay does not use a CAD program for this??

These are "Mechanical drawings" that should be generated in a CAD program, not "Reports"
These drawings can be "Logged/Stored" in your database, ...but they should not be generated by your database application.

Perhaps this all falls outside the scope of this thread, ...but...

So we are looking at your paradigm here.
Typically, a company will design a "Door" with a CAD program.
From that mechanical drawing, ...they will build a prototype.

The mechanical drawings could then be scanned and/or stored as images (or PDFs)
Then linked into the Access application (via Attachment fields, File Linking, ...or OLE fields)
Then multiple Related drawings could be displayed in a "Report".

Access is not a CAD program.
When the drawings get more complex, (and they will) Access will fall flat.
For example,...how would you generate a 3D rendering of that Door, ...to be sent to one of the new 3D printers for prototyping?
Things that would take "seconds" in a CAD program would require you to create/modify massive amounts of custom code.
For example "make the door 2.5% bigger",...or if certain "Boxes" needed to be a custom size.

Access does not have Rendering, Automatic dimensioning, scaling, rotation, Axis flipping, Stored Shape Galleries, Chamfering, mirroring, ...etc
A CAD program can also detect mechanical confilicts (such as a hinge that makes contcact with a door frame)

I would be interested in seeing a CAD package that works with Data from Access do you know of any

AutoCad will, ...but it is not as simple as having a table of dimensions and AutoCad automatically "creating" a detailed drawing...
;-)

Surely, you can "force" Access to do this, ...but as you can see with your issue here, ...a simple task like building rectangles, creates this massive thread.
And again, ...what happens when the designs become more complex?
You can force Excel or Word or even PowerPoint to do this as well...

Again, companies do this sort of thing all the time, and none generate "Mechanical Drawing Reports" directly in Access.

JeffCoachman

Did you say that you do not get the problem on the report?

See the screenshot I posted:
https://www.experts-exchange.com/questions/28693553/PSet-problem.html?anchorAnswerId=40859919#a40859919
I used the code you posted (For one box)
...and it looked fine in Print preview and the actual printout.

I cannot say what happens when a loop is used to generate multiple boxes...

Again, are you saying that all of the drawings you have in your "report" are actually "Shapes" generated in Access?

JeffCoachman

I wonder if I have accidental changed some standard setting because this is something that I have never noticed before in access 2002.

I get that line in every box I draw regardless of any looping.

Yes all of the drawing is produced by access

OK,

Again, the Box appeared just fine for me...
(Access 2013, Win 7)

I'll admit I am confused.

Private Sub Detail_Format(Cancel As Integer, FormatCount As Integer)
 Me.PSet Step(100, 100)
 Me.Line Step(0, 0)-Step(100, 100), 0, B
 End Sub

I cannot make sense nor find Help or Google info on your use of Step in this context.
Still, In Access 2003, pasting that snippet into a new mdb with a new report draws just a little box.
Commenting out the PSet line makes no visible change to the report output.
Commenting out the Line line leaves a blank report.

Why are you using PSet at all?
Are you just using it to set CurrentX, CurrentY so that you can omit them from the Line() call?

Why are you using PSet at all?
 Are you just using it to set CurrentX, CurrentY so that you can omit them from the Line() call?
Answered it by experimenting.
That's what you are using PSet for.

In Access 2003, this code
Private Sub Detail_Format(Cancel As Integer, FormatCount As Integer)
Dim x As Integer
Dim y As Integer
For y = 1 To 10
    For x = 1 To 10
        Me.PSet (500 * x, 300 * y)
        Me.Line Step(0, 0)-Step(100, 100), 0, B
    Next x
Next y
 
End Sub

Gives the attached result

Try a brand new mdb and report.
See if the problem follows Access, or follows your report!

I wonder if you have ScaleMode problems, and so your PSet, instead of being an insignificant pixel, has become a chunk of real estate?
PSet.pdf

Nick67
It may be a chunk of real estate. I will try it out. You have it exactly that is what I am doing.

Jeff, I have always enjoyed doing things in an unconventional way. When my users click a preview or print button the report I attached just gets done. Everything is proportional. So if one of 100 doors needs a change of height or width or needs an extra hinge they make the change and the program will print a new report instantly with no updating of any drawings no creation of PDFs (I don't know how long it would take a standard PC to create PDFs for a hundred doors) and no large files to worry about. This is a very industry specific application so it is unlikely that someone will want to 3D print a door. 3D views would be interesting but every 3D door image I have seen looks amateurish and would serve no purpose.

"The mechanical drawings could then be scanned and/or stored as images (or PDFs)
Then linked into the Access application (via Attachment fields, File Linking, ...or OLE fields)
Then multiple Related drawings could be displayed in a "Report"." I do understand how this could be done but by having access do it means no work is required at all.

I am still in the dark about Step, if either of you could shed light on that, it would be great!

This problem only manifests in preview, and not in print or PDF, correct?
Does this problem manifest in a new mdb?
Does it manifest on all machines in your environment?
Does it manifest on all versions of Access you run?

(Jeff and I don't have the problem on A2003 and A2013, so these are logical questions to determine the scope.)

Hi Nick
 Step, as I understood it, meant that you are "stepping" a certain distance from the previous location otherwise a command like PSet 0,0 would take you away from the last position and put you up in the top left hand corner. In machine operating terms it is called incremental movement where every next move is in reference to the last position. So x100 ,y100 will take you down and right by that amount even if it takes you off the page. The other term is absolute coordinates which refer to any top left corner or any previously stipulated x0,y0 reference point. So looking at your code I think if you took out the pset line you would print 100 squares joined at the bottom right corner.

I am checking the same code on new DBs,

This code gives attached file Capture
Private Sub Detail_Format(Cancel As Integer, FormatCount As Integer)
        Me.PSet Step(200, 200)
        Me.Line Step(0, 0)-Step(2000, 2000), 0, B
        Me.PSet Step(100, 100)
        Me.Line Step(0, 0)-Step(2000, 2000), vbRed, B
End Sub
This code gives attached file Capture1
Private Sub Detail_Format(Cancel As Integer, FormatCount As Integer)
        Me.PSet (200, 200)
        Me.Line Step(0, 0)-Step(2000, 2000), 0, B
        Me.PSet (100, 100)
        Me.Line Step(0, 0)-Step(2000, 2000), vbRed, B
End Sub
Capture1.JPG
Capture.JPG

I have now tested this on other new databases including blank dbs and still get same problem. I would just give up but there must be a reason why this is happening with access 2002 but not any of your DBs?

Derek

Still unsure of why simple ectangles cannot be used...

Still unsure of why simple rectangles cannot be used...

In your images, what is wrong with them?
I get a 2mm long line on my report.
Where is that in the images?

I must admit, I am out of my depth here, and dealing with CTB-Locker at the moment, so please forgive me if I am not as helpful or prompt as usual.

Hi Jef

When you need 20 boxes one above the other with the PSet Step all you need is repeat 19 times. Without step all have to be coded

See Nick's loop example above

No problem Nick The 2mm line should not be there.

Yes, but I don't see that line in your images from #40866798
I just see the rectangles.
What am I missing?

Hi Nick

That is the question. I said earlier that it may be that I have accidentally set some weird setting somewhere but I cannot see it. The only thing I have not tried is  a line type that matches the reverse colour of the screen background. I wonder if there is a setting for line colour as background.

I think it must be something like it because it has only recently occurred. Or perhaps some Microsoft update has changed something that only effects Access 2002

Derek

Sigh.
We seem to miscommunicating.
In #40866798,  you posted two images.
I assumed they were images demonstrating the 2 mm line problem.
I don't see anything wrong with them.
Was I supposed to see some anomaly?
If there is an anomaly can you circle it on some new images?
Or explain the purpose of the images if all of this is way off-base?

Now PSet is documented here
https://msdn.microsoft.com/en-us/library/office/aa221546(v=office.11).aspx
From that
The way the point is drawn depends on the settings of the DrawMode and DrawStyle properties.
DrawMode is documented here
https://msdn.microsoft.com/en-us/library/office/aa195856(v=office.11).aspx
Setting DrawMode to 11 turns the drawing off.
Since you are using PSet to move the starting point and not actually draw, you may be able to wrap the PSet in a couple of DrawMode calls that turn the drawing off for the PSet call and back on again after it is complete.

My apologies. I thought you may have tried the coe in a report. On my capture it was as clear as a bell so here is an enlarged version. The small line appears every time I use PSet to position a start point.

I do appreciate that I can switch draw mode off. I just cannot get to the bottom of why it draws it at all
Capture2.JPG
Capture1.JPG

PSet is meant to draw, after all.
You shouldn't be surprised if it does
I took your code from #40866798
Changed it into Private Sub A and Private Sub B
Results attached.

Note that sub A doesn't give me two whole boxes
Open the PDFs and blow them up to 1000%
You can see the one pixel that results from the PSet call, but that's all.

So, what are all your defaults for the things that affect how Line and PSet work?
Report1a.pdf
Report1b.pdf

Sorry for delay in replying Nick.

You only get 1 pixel so how is that meant to "draw". I did not know that PSet did anything other than set a point. Which is what you would expect. So by "Draw" you mean draw a point. That would be OK but here is what it does in my reports. (Attached).

AS I said earlier this problem appeared suddenly where previously there was no line or even point as far as I could see. Also if the PSet is started at the point where the square starts why do we see even a pixel? It should be under the box line anyway?

Thanks Nick
Derek
Capture1.JPG
Capture2.JPG

Fabulous

Thank you
Derek

Well, I am glad that it got flanged up!
You're welcome

Nick67