We run IE11 on Windows 10 Technical Preview Build 10049
This javascript check returns false:
if ("ActiveXObject" in window) alert(‘ActiveX supported!’);
and this line
var objBonPrinter = new ActiveXObject('dispi.commport.Bonprinter');
returns the error "ActiveXObject is undefined"
So it seems the problem is not in the ActiveX component but on a higher level?
We have set all the security settings to allowed, just like we do in IE11 on Windows 8.1 which does run the same code fine.
edit: it works if we use IE11 in compatibilitymode. But it doesn't work without.
Starting with IE11, the ActiveXObject property is hidden in favor of cross-browser plugin detection.
You'll need to update your code accordingly.
Hope this helps...
-- Lance
I tested on the last Windows 10 Technical Preview Build 14372.
Unfortunately ActiveXObject doesn't work and there is no information in the logs.
And Yes, it works if we use IE11 in <=8 compatibility mode only.
As I know it, IE9 has different engine as compared to IE8 and I guess it is bug of IE Technical Preview.
Related
Having very strange issue with Delphi Chromium 3:
When running the vanilla demo app, (GuiClient), if I separately try to open a Microsoft Excel 2010 file (just double clicking on a file in Explorer,) it takes significantly longer than if the Chrome demo is not open. OS is Windows 7.
I have traced this to the "CefSingleProcess := false" line. If this line is commented out, everything works fine. I understand from the DCEF3 developer that Chrome can "run in more than one process" but I am not sure how this could affect the file system.
Even if this is not a fixable issue, I would be very curious to understand what is happening here. :)
I have tried to use the new TFileOpenDialog and now my application is not compatible with Windows XP anymore. I find out that TFileOpenDialog only works on Vista and 7. It seems that TFileOpenDialogand does not check if it is running under Win XP in order to automatically and silently downgrade to TOpenFileDialog. Instead it just shows an error message. There is something I am missing? There is a wrapper that offers this functionality or I have to switch back to the classic TOpenFileDialog?
I don't understand why Embarcadero had to toss Borland's help system and build a new one (much worst) from zero.
Use TOpenDialog and set UseLatestCommonDialogs to true. You don't get the new (Vista and up) properties (like OkButtonLabel) but at least the look and feel will be fine from a user's POV...
Yes, it is called TOpenDialog.
Does anyone have any suggestions on the compatibility setting on Windows 7 for the Delphi/Paradox Database desktop program so that it displays properly in Windows 7 (x64)?
We've tried quite a few combinations of selections on the Compatibility tab on the .exe's Properties screen. But, none of them have eliminated fixed our problem:
It runs fine, but the buttons on the structuring screens are missing their text and are not clickable. The work-around is to use the keyboard shortcuts for these buttons, but obviously, although workable, that's not ideal.
Pre-emptive prose: Yes, we know we're on risky ground and need to migrate away from Paradox, which in some future version of Windows will not be supported. (But, we've got a million+ lines of code and migration won't be easy...)
I can confirm that disabling UAC and moving Database Desktop out out C:\Program Files makes buttons work again.
Before:
After:
A few points:
Try running it with UAC disabled.
Make sure you have all the BWCC-dlls and stuff in the right places too.
On Windows XP, check which fonts is uses, make sure those fonts are installed too.
Nothing worked for me with Delphi 5 Database Desktop on Windows 8, until I realized that I had also installed it through the Delphi 4 setup - and that version of DBD opens fine for me. Hope this helps!
so easy answer :
don't use delphi menu to open desktop database but just navigate to this directory
"C:\Program Files\Common Files\Borland Shared\Database Desktop"
and run DBD32.EXE
you can also create a shortcut to it on desktop or quick launch on taskbar
i use delphi 7
We have a few different programs all compiled together in the same suite, recently we had a bug reported that "The Right Click Shortcut Menu was missing."
So as with any bug I tried to reproduce it and couldn't. No matter what I did the right click menu appeared on my system.
My first guess was that this was an OS issue. We know it works on Vista and XP, but on Windows 7 it doesn't. Unfortunately this issue only affects one of the programs in the suite and seemingly only on this one machine. AFAIK there isn't any code we've written to allow or prevent the default menu appearing so I'm not sure why it only affects one program.
The machine with the issue is a 32-bit machine running Windows 7. There was another issue to do with the regional settings (we have noticed backwards date formats even though the OS thinks it's UK it had been displaying MM/DD/YYYY format, but this was fixed when changing the regional settings to something else and back again). This did not resolve the issue.
Besides writing a new context pop-up, does anyone have any idea how I would even start to diagnose this issue? Is there an API I can call to pop-up the default menu so I can monitor its behaviour? some windows message I can intercept the check its all running as it should be?
Download Delphi 2007 December updates to fix this problem
or andy Context menu popup delay bug fix unit
In Delphi (2007) I'm used to setting a bookmark with CTRL-SHIFT-0,1,2 etc.
Since I've upgraded to Vista x64 the above no longer works. I can still set a bookmark with CTRL-K-0,1,2 etc but I'm habituated to the traditional way (plus it's quicker).
Does anyone know why it's not working for me?
I had the same problem. Some more investigation showed that it is caused by a change in Vista.
Input method editor keyboard shortcut (CTRL+SHIFT+0) switches the input language in Vista. The following link shows how to disable this shortcut and thereby make it available to other applications (including Delphi) again: http://support.microsoft.com/kb/967893.
I am running on Windows 2008 Server 64-Bit (which is based on Vista) and I use CTRL+SHIFT+1 to set book marks and it works fine. At home I have Vista 32-Bit and that works fine too.
You might check to make sure your OEM didn't install some crazy keyboard hook on that or something. I've had that happen before where some key combinations were remapped by a background program and it prevented them from working in Delphi.
Programmers use a lot more key combinations then most "normal" users.
Verify that you don't have system wide hot keys that conflict with those. I had the same problem with Trillian hijacking some Delphi shortcuts.
As already mentioned, Vista is using that key combination.
If you don't want to disable it, Ctrl+K CTRL+0 is the old school method to set bookmark 0.