Ah, I see.
Well, if you really want colliders at the edges of the screen then you would have to have them on a layer that matches the same x,y scroll rate as the layer your player sprites are on. This means that you will have to update your colliders x,y coordinates every cycle to match up with the scrolling screen. This can cause some buggy problems, though... if you manually set the x,y of a solid object like your screen barrier, then it's possible to move it into a position where it intersects with your player sprite. It would take a lot of tricky custom events to compensate for this.
If you're dead set on having barrier objects then you might do something like giving your barrier Bullet Movement. That way you can tell it to move towards where you need it on the screen rather than set it's x,y manually (it will still "push" solid objects rather than intersect with them). But even this method is getting rather complicated and convoluted for what you want to do.
The simplest, most efficient method would be to ditch the detectors altogether and use math. If you don't want your sprites to go half-way off the edge of the screen then make your edge collision condition look like this:
sprite.X Less than (ScrollXRight-numOfPixels)
This will check whether your sprite is inside the visible play area as compared to the right edge of the screen, where numOfPixels is the amount of space you want to leave at the edge.
If you want to check if it's in the play area as compared to the top edge, you'd do like so:
sprite.Y Greater than (ScrollYTop+numOfPixels)
You can check your second player's location just as easily using x,y value comparisons, so there's really no need for the barrier objects.