After much data-sifting, I think I've finally cracked the internal logic and formula for exactly how the DDS-3X25 sets the DAC clock and decides on the number of points for any given frequency. I've written a little piece of software to demonstrate.
Normally, to generate a certain frequency, you first send the desired frequency to the DDS-3X25 with the DDSSetFrequency command - which causes the MCU to set the DAC clock rate, and returns to you the number of points you should use to create the waveform and the number of cycles of the wave within that given number of points (since, as discussed previously, the DDS-3X25 is missing a built-in lookup table of simple waveforms). Once you create the waveform sample, you download it to the device with the DDSDownload command, specifying again the number of points, which in turn sets the actual frequency generated by the device (DAC clock rate / (points / cycles)).
But once you do the above, you can actually change frequencies again by just altering one or the other settings, but up until now, I've been unable to figure out exactly how to do this predictably.
To test the software, just hook the Output to the Count In (no 50ohm termination required):
1) Enter a number in 'Current frequency'
2) Click 'Calculate data based on current frequency' - this will cause the software to calculate the real frequency, number of points, and DAC clock rate the 3X25 will use.
3) Click 'Set frequency and download points' to send the data to the device and see the actual output in the Frequency Counter box.
4) Then play around with either changing only the frequency or the number of points, clicking the associated 'Calculate' button first before sending to the device, then downloading only that new frequency or new number of points to see the actual change.
To test the precision of the calculation, enter 195312.49 as 'Current Frequency' and calculate. Note the real frequency and number of points, then download to the device. Then unlock and enter 195312.5 as 'Current Frequency' and calculate. You'll notice that the real frequency produced by the device is exactly the same, but the number of points which will be requested by the Hantek has changed, based on it's internal logic.
Notes:
1) On my Hantek, it appears that the DAC clock divider drops one bit on frequencies < 60kHz (@Mecha - this has nothing to do with the number of points returned by DDSSetFrequency - it's internal to the FPGA) or else my Count In is drifting on those frequencies. In any case, I've included a setting (Drop Bit < 60kHz) to include that in the calculation. It's off by default, but the software starts with a nice slow test frequency of 100Hz already entered and calculated. Download it to the device and check the Counter box; test by clicking the Drop Bit On and re-calculate to see if it is more precise.
2) Some combinations of frequency and points will cause some drifting of the frequency - this is just inherent in the design of the hardware.
3) Some changes of frequency and/or points will not change the output frequency because they are not altering the DAC clock rate; for example, if you start with a frequency > 48828.125Hz then the DAC clock will be set to full speed (200MHz) - so trying to change the frequency by only giving the device another frequency > 48828.125Hz won't work since the clock is already running at full speed. Instead, change the frequency < 48828.126Hz or change the number of points.
4) I'd appreciate feedback from anyone who tries this - just let me know if it's working correctly on your device or not - and if the Drop Bit was needed for precision. Thanks!
Edit: Added another small piece of software that tests running an (almost) logarithmic sweep (using the technique detailed above) by just changing the DAC clock rate - not the points - so no delay, no pauses, and perhaps no glitches. I'm currently without a scope, so I can't look at the output, but perhaps Mecha or someone else can check what it looks like when it changes frequency. Just start, chose a waveform, and click 'Run Sweep' (use 'Repeat Sweep' for continuous).
SweepTest.zip (73.7 kB - downloaded 2 times.)Edit2: Refined the sweep test - it now does an almost perfect audio logarithmic sweep - from 10Hz to 40kHz - by reverse calculating dividers to set the DAC clock to in order to generate the desired output frequency, but without downloading points (which causes delays and glitches). It gets as close as possible given the hardware limitations, and only misses a couple of frequencies. Hopefully it will be glitch free.
DDSClock.zip (15.64 kB - downloaded 5 times.)Edit3: Fixed a bug I just noticed in my clock test software which overwrote the original number of points (internally) when downloading just the frequency - causing subsequent changes to just the frequency being calculated incorrectly. I think (err... hope

) it's bug-free now.
SweepTest2.zip (74.33 kB - downloaded 5 times.)Edit4: Attached working... um, I think

SweepTestv3. Also, accuracy of clock formula hack confirmed by another 3X25 user - so here it is:
To get the DAC clock rate for any frequency:
HantekClock = 200000000
divisor = Int((HantekClock / freq) / 4096) * 2
If divisor = 0 Then divisor = 1
DACclock = HantekClock / divisor
'To get the number of points and periods which the Hantek will return for a given frequency - and the real frequency the device will output (not what you give it):
periods = 1
points = DACclock / freq
If points < 2000 Then periods = Fix(4096 / points )
points = Fix(periods * points )
realFrequency = DACclock / (points / periods)
'The following code corrects the drop bit error (if your device has it) in the software output, and gives me an exact frequency count at any setting. The code is done this way because sometimes the real frequency calculated is > 59988Hz, while the original frequency requested was below:
If realFrequency < 59988.003 And periods = 1 Then realFrequency = HantekClock / (points * divisor - 1)
If realFrequency >= 59988.003 Then realFrequency = HantekClock / (points * divisor)