In my Debian with KDE, there is nothing in /opt, because everything installed on this system is installed through the package management system. Years past, when installing firefox from source I remember having to install it in /opt so it can be used by all users or something. The files the shortcut points to can either be an executable file, shared library, or a script. Through my file manager dolphin (nautilus in Gnome), when I right click on an executable in /usr/bin and select properties, there is a monkey wrench icon in the window for settings, by clicking on this monkey wrench the "edit file" window appears. There is a list called "Application preference order" which is blank, meaning there is no application used to do anything with an executable as the executable executes commands and runs an application.
Now, when I do the same with a script in /usr/bin, kwrite (gedit in Gnome), is the only application listed in the "Application preference order" section as you can edit a script with an editor like gedit. A script is sort of an executable also when it is in your path, and you are permitted to run it by issueing a command with a dot and forward slash before the name of the script. An example, for all intensive purposes, let's just say firefox is run from a script, the command would be: ./firefox.
This may not be the way your desktop shortcuts issue their commands. For instance, I right clicked on a link in my main menu for the iceweasel (firefox) application and selected "add to desktop" to place a shortcut on the desktop. Iceweasel is run by a script in /usr/bin called firefox (I think). In the shortcut's properties, the command is: iceweasel %u.
Here's what I suggest, look at what kind of file it's pointing to in /opt/program folder/bin, if it's a script, look in /usr/bin for a script of an application you know has a shortcut in the main menu, then go to the main menu and right click or whatever it takes to create a shortcut for that application on the desktop, then look at the properties of that shortcut to see the command structure and compare it to the shortcuts that open gedit to see if they are the same structure or not. If the command is of the same structure, check the permissions of the script or executable in /opt/program folder/bin as it might be a permission, owner or soft link issue. I say softlink because if I remember correctly, in the past when installing flash from source, some soft links had to be created to other files elsewhere in the system.
You can also try creating many different shortcuts from other applications through the main menu, if these shortcuts work, look at the different command structures and try changing the commands of the shortcuts that don't work properly to see if you can find the right structure, worst comes to worst, if not, just edit it back to what it was originaly.
So, if you can't figure it out through this process of elimination, post the type of application that is not comming up where gedit is run instead. This way, if someone else has that sort of setup with that application, it'll be easier to figure it out.