I'm having trouble understanding what you are actually doing given how you described it.
I don't know what you mean by "count every timing to 10.24 micro seconds". The only things I can think of that you might mean are a clock period for a registered portion of your design or the grid size for the simulation, neither of which will affect the delays shown through combinational logic in a timing simulation.
You said, "Basically in the timing simulation I want to eliminate the simulated propagation delay." A timing simulation will always show the device propagation delays. Any combinational logic function will always have the delay through a LUT or CPLD macrocell. You need to do a functional simulation (as in std_logic's post) to have no delay between the input and output of a logic function.
Make sure you are looking at what you think you are looking at for the "simple logic gates", which I think you are saying appear to have zero propagation delay. One logic gate like a NAND feeding another logic gate in your source file might be combined together into a single LUT/macrocell during synthesis. For a functional simulation, you can see the output of each logic gate separately with their transitions at the same time. If you are doing a timing simulation, though, you can see only the output of the LUT/macrocell no matter how much source-file logic is in that LUT/macrocell; the intermediate logic gate output nodes won't exist for the timing simulation. If you really can see each logic gate output separately in a timing simulation, then each gate must be in its own LUT/macrocell, but that means each gate is going to have some delay.
When you think you have zero delay for "simple logic gates" but nonzero delay for a latch, could you just be zoomed out far enough that you don't see the small delay for the logic gates? You mention timescales in microseconds. If you are zoomed out far enough to see multiple microseconds, then the nonzero delay through each LUT/macrocell will look like zero. Zoom in enough so that you can see what is happening at the scale of nanoseconds.
If you are using a repetitive signal pattern with input transitions separated by times on the order of nanoseconds, you could think you are seeing zero delay when you are actually seeing the delay from the input transition from one cycle of the repetitive input signal just happen to cause an output transition right about the same time as the input transition for a later cycle. When the input transitions are closely separated compared to the device propagation delays, it can be hard to tell which input transition caused which output transition.
If you did not follow the latch coding guidelines I referred you to or if you created your latch with logic gates in a schematic, you might have gotten a result that Analysis & Synthesis did not report as a safe latch. In that case, strange things can happen to the latch output in a timing simulation and in real hardware. You need to zoom in to the scale of nanoseconds to see whether the latch output has clean transitions without glitches or oscillations. More important, you need to make sure the Analysis & Synthesis report says the latch is safe. Refer to the Quartus handbook to see how this is reported.