I don't think it is possible to do that in XFCE power manager. However, you can make a script to both lock screen and turn it off, and make it so that it is launched as soon as you close your lid, overriding power manager's settings.
How to launch a custom script is reported in the official Ubuntu help page. I'll write the passages sequentially, to understand the reason of each step read the original post. Maybe it's not the easiest process around (it is pretty easy anyway, as you just have to input a series of specified commands and fill files with precise content), but I think it is the only way to go. Also, is pretty canonical, both with the lower-case and capital C, as the solution is in Ubuntu's official help.
First, create a script to make environment variables available for root, so that it can launch commands in your normal user's environment.
(I put mousepad in the commands as it's the default text editor for XFCE. Replace it with GEdit, SciTE, Emacs, nano, vim or whatever editor you use)
$ mousepad ~/export_x_info
With the following content
# Export the dbus session address on startup so it can be used by any other environment
sleep 5
touch $HOME/.Xdbus
chmod 600 $HOME/.Xdbus
env | grep DBUS_SESSION_BUS_ADDRESS > $HOME/.Xdbus
echo 'export DBUS_SESSION_BUS_ADDRESS' >> $HOME/.Xdbus
# Export XAUTHORITY value on startup so it can be used by cron
env | grep XAUTHORITY >> $HOME/.Xdbus
echo 'export XAUTHORITY' >> $HOME/.Xdbus
And make it executable
$ chmod 700 ~/export_x_info
Add it in Settings → Session and Startup → Application autostart to Set it to run on startup.
Create /etc/acpi/events/lm_lid
# mousepad /etc/acpi/events/lm_lid
With this content
event=button/lid.*
action=/etc/acpi/lid.sh
This will execute /etc/api/lid.sh when lid button is triggered. Let's create it
# mousepad /etc/api/lid.sh
#!/bin/bash
/home/%user/lid_event
(obviously replace %user with your username)
This means the script will execute /home/%user/lid_event. Let's create it too
$ mousepad ~/lid_event
grep -q closed /proc/acpi/button/lid/LID/state
if [ $? = 0 ]
then
/home/%user/close;
else
/home/%user/open;
fi
This will execute ~/open if the lid is opened and ~/close if it's closed. Again, let's create them:
$ mousepad ~/close
Since to turn screen off you need xset dpms force off and to lock it you need xflock4, will write this inside close:
#This runs so that root can run the following command under the user's environment
source /home/%user/.Xdbus
#Lock and turn off screen
DISPLAY=:0.0 su %user -c "xflock4 && xset dpms force off"
Inside open, as suggested by Ubuntu's help, you can play a sound of your choice (I made a test with Barney Gumble's burp)
#This runs so that root can run the following command under the user's environment
source /home/%user/.Xdbus
#play a open sound
DISPLAY=:0.0 su %user -c "aplay %path/to/a/sound/of/your/choice"
Let's make them all executable
$ chmod +x ~/lid_event
$ chmod +x ~/open
$ chmod +x ~/close
Restart acpid
# /etc/init.d/acpid restart
Launch ~/export_x_info (or restart your laptop so that it is autolaunched on startup) and close/open your lid to see if it works.
Note: in my laptop, locking screen would also turn it off, so I couldn't 100% test the double action, but it worked in locking it. Also, the help page puts, as an example, an action to change Pidgin's status as away when you close the lid and as "I'm here" when you open it, very useful.
TL;DR (if this issue should ever occur to a lazy person or a newbie): input the commands in the gray background (# means you need elevated root privileges, or simply type sudo before the command, while $ means you should input the command as regular user). When the command invokes a text editor (i.e., mousepad) copy and paste the part in the yellow background in your editor, then save and close.
Best Answer
Power management is a matter of what software you have, not what distribution installed it, so on some level the answer is “yes”. It's always possible to re-create the same configuration on one distribution as on another distribution.
However, power management depends on the precise version of the software involved, especially the kernel. At any point in time, different distributions are likely to have different kernel versions, and to have applied different improvements and bug fixes. So in practice, especially if your hardware has only recently become supported, you might find that one particular version of one distribution works better than another version of the same distribution, or a version of another distribution.
It's also possible that different distributions have configured things in different ways. Sometimes hardware requires proprietary blobs to function optimally, and not all distributions install these by default or make it easy to install them explicitly. Distributions might also choose different defaults when there's a choice between, say, a solution that works for everyone but doesn't give optimal performance, and a solution that's optimal for 99% of users but crashes in 1% of the cases.
In many cases, for hardware issues, if you find configuration tips (e.g. some kernel options to apply) about one distribution, they're often applicable to other distributions. In particular, there's often a lot of information on the Arch Wiki that's useful even for people who run other distributions. However, if your problem is that your drivers are too old, you may need to obtain more recent drivers.