I have been handed over a Silverlight 4 application that uses the Google Earth API. We have an issue with newer versions of Google Earth: In Internet Explorer, the map displays as a white background with the text "ATL 10.00". In other browsers, the background is just white (cannot see any text).
It works with Google Earth version 6.0.3.2197 but not in any version after that.
I have read this thread
- but none of the suggestions there worked. I must note, though, that the JavaScript code for initializing GE in Silverlight is rather complex, but as far as I can se, the initialization of GE is done in the google.setOnLoadCallback function.
It would be nice, if someone knows what exactly the "ATL 10.00" message means.
Any help would be greatly appreciated!
EDIT
Please let me know if I should clarify in further detail.
UPDATE:
The problem was caused by 2 things and probably a combination of the two:
1. The container for the map was added dynamically with JavaScript into another div
2. The container's width and height was set to 0 in order to hide the map.
So, the solution for me was to render the containing div together with the rest of the DOM. In order to "hide" the map, I positioned it absolute beyond the bounds of the screen.
Hope this can guide others to solve similar problems.
ATL in referring to the Active Template Library in Windows. ATL in Windows is a set of template-based C++ classes that let developers create COM objects (rather like MFC and ActiveX).
10.00 here simply refers to version of ATL being used. Seeing it probably means that the COM object (GEPlugin in this case) has not been created or initialised properly in the browser. The blank screen with the version number in the centre is what the plugin looks like before it loads content.
So, it is not really an error message at all - indeed one could say it is really the failure of an error message to appear that you are seeing.
Anyhow, to answer your question in simple terms it means than the version of ATL that was used to create the plugin was version 10.00.
In practical terms it means that the plugin failed to initialise properly for some reason.
Related
I'm looking for dock layout engine for angularjs written in typescript. I found Dockspawn but it is written in DART and it's not compatible with the rest of my project. Does somebody know any dock layout engine (even paid ones) for angularjs in typescript?
I think your real problem is that dockspawn was abandoned. This is something I built at my company (which, sorry, we don't sell software)and it turns out that Angular is the worst thing you could use to build a layout engine like this.
Managing scope chains among components that are constantly changing positions, opening/closing, resizing, and floating is entirely too complicated for this type of project. You will end up with 15 step bug reports everywhere, and unless you have a perfect algorithm set in place before ever developing anything you will end up spending weeks re-writing code.
Solution (and not the one you want to hear): drop it. Web design is meant for developing pages within the browser, not for developing windows with tabs within your browser window which is full of tabs. The control and flexibility is very nice, but there is always a way to provide the user with just as much control by setting up panels on the page in the positions in which they will be consistently used the most.
Sooner or later someone will develop what you are looking for and release it, but it probably won't be in Angular and it's definitely going to cost money.
You should be able to use Dockspawn because at runtime DART is JavaScript, so as TypeScript. You just need to find a way to make TypeScript aware of Dockspawn and you can do that using a Type definition file.
The types definition file for Dockspawn is available online.
You can install this kind of files using a tool known as tsd. You can find a basic example here.
I'm building an application that is using CEF 3 (version 1650) in WPF (meaning I'm using OSR mode) using Xilium.CefGlue as a wrapper.
After a lot of research I've found several features I can't get to work nor workaround:
Focus Management - I need to tell when the last focusable item in the page lost focus due to a Tab press (or the first item due to Shift+Tab)
Javascript Alerts - I got them to work for standard schemes, but not for custom schemes (also found a bug regarding it). I'm looking for a way around it.
Favicons - Seems CEF3 did not implement favicon support. I guess I can look for favicon.ico in the root directory for standard schemes, but what about favicons linked in the HTML itself?
User Permission Notification - I only found permission request events for geolocation request, but I also need for other things such as getUserMedia. Any idea how?
Zoom - This one works except for getZoomLevel, that for some reason always returns zero. Does anyone knows why or how to get around it considering it does remember each page's last zoom?
Process Model - I can't get multiple browser windows opened manually (that is, not via javascript's openWindow) all with the same custom scheme to open in the same render process (already tried all different process model parameters I know of). As far as I understand, it should be possible. What am I missing?
Thank you in advance for your help.
Focus Management is it OnTakeFocus you are looking for?
Favicons has an open enhancement issue in the CEF project
For anyone who finds their way to this question, favicon support is now available in the official CEF builds.
The question says it all really. If you are writing a WPF application, how are you integrating the application help? What is the state of play in mid-2013?
It seems that there is no clear answer to this from an afternoon with a search engine, but several options:
Write your own fancy tooltip based help (but where are you getting your data from?)
Use .CHM files and the Windows Forms help system (seems archaic to me).
Use Microsoft Help Viewer 1.X or Microsoft Help 2.0.
There is some confusion as to which is more recent / approved of by MS. It appear Help Viewer 1.X might be the recommended option over Microsoft Help 2.0. It doesn't help that the names are so similar...
What is the status of 2.0? Should we use it? Was it ever fully deployed?
Use a third-party product to author your help files and link to them somehow - DocToHelp/NetHelp, NetAdvantage on-line help, etc...
Furthermore, what XAML based mark-up / attributes are you using to provide the necessary context? What is the recommended method?
It seems surprising there is no clear path for supporting application based help in WPF.
My current preference is to use a third party help authorizing system to generate HTML based help.
We then use a WebBrowser to display this help as needed. The authoring system we use makes it fairly easy to extract out a single page from the main help (each "topic" is a single HTML file, and can be included with full contents or not as desired).
Granted, this definitely felt like a bit of a nasty hack at first - but once we wrote the basic plumbing (some attached properties for xaml to specify attributes for context location and add behavior to trigger help, etc), it's fairly clean.
One very nice advantage to this approach, however, is a single help system build works perfectly in all contexts - we can include the documentation online, expose it locally for use in a browser, and use it with context from within our application directly.
I am planning to make a web application, using silverlight for frontend. requirement is: this frontend will be just an empty shell, and it must be language independent. it will get everything it needs to display and use from server, therefore making it language independent.
i tried to find tutorials, but there is nothing.
as far as i understand, silverlight uses xaml for all its data, so just generating it with whatever language i want shouldn't be a problem. but i don't have any silverlight experience or knowledge, so i'm not sure what is the best way to do this. for example, i don't know how will new content be generated, and what kind of structure silverlight requires.
can anyone give me some starting points?
Your requirements are rather demanding. If i can summarise:
silverlight will be the front end (or container)
you don't know what it will be showing
the content may be dynamically generated
everything, including the visual content, will be retrieved from the server
If i have misunderstood then by all means correct me or adjust your question.
Those requirements are not trivial, especially when you have no prior experience in Silverlight. Fetching data from the server is a normal behaviour in Silverlight, but fetching any generated UI content will be a slow and inefficient use of the technology platform. Silverlight is delivered via the browser, and runs on the client. If you are going to have generated UI, then you may want to consider using straight HTML instead (you can generate the contents using ASP.Net or a scripting language such as PHP). Alternatively, you can generate your required UI views from within the Silverlight app itself by either swapping in and out the appropriate pre-built piece of UI (or controls), programmatically adding new controls into the visual tree, or by loading XAML using the XamlReader class.
This answer may or may not help you much, but like i said before - put some more specific details into your question and you will get more specific answers (either add comments under your question, or post a new more specific question if you cannot edit your current one).
Edit: i have just come across this blog article from Jeff Prosise explaining the use of the INavigationContentLoader interface in Silverlight 4 to dynamically load pages from either remotely or locally. It is a detailed write-up, with a lot of code samples, it may be of use to you.
I would suggest you start at http://Silverlight.net
The "Learn" section has lots of videos that can get you started. http://www.silverlight.net/learn/
I am working on my first DotNetNuke website and there is a requirement for all the custom module functionality I am developing to be available with JavaScript disabled.
However, when I create a module that contains a simple submit button, i.e.<input type="submit" />, DotNetNuke displays a critical error with JavaScript turned off but works as expected with JavaScript turned on.
When I attach to the running process using Visual Studio, the unhandled exception is thrown from admin/Skins/Nav.ascx.vb line 177. The inner exception message is "Invalid JSON primitive: ."
My research online only managed to turn up this forum post (Postbacks are not working when Javascript is disabled in the browser) that appears to be the same problem as mine, but no solution is provided.
Can anyone shed any light on this issue? Is it viable to be attempting to write non-JavaScript functionality in this version of DotNetNuke?
Update: it turns out that another website designed recently with Dot Net Nuke by the company I am working for is having the same problem with non-javascript postbacks when using DNN version 5.1.4 but it does not have the problem (i.e. it can postback without javascript) in DNN version 5.0.1.
So perhaps a hard dependency on javascript has been introduced at some point after version 5.0.1. We are investigating this possibility further and I will keep this question updated as we go. Obviously I still welcome anyone's input on the subject.
Update: i've started a thread on the Dot Net Nuke forums to see if I can get any help there. If any solutions come up I'll post them here. Trying to find official DNN stance on support for javascript disabled functionality
One of the developers in the office found a workaround to get postbacks working with javascript disabled. Unfortunately since he does not have a Stack Overflow account, I will try to translate his solution as best I can for those who are interested. Bottom line is postbacks with Javascript disabled is possible once you make a few changes to the Dot Net Nuke environment.
Step 1 - Change the menu module. In our case we used the Telerik RadMenu.
<dnn:NAV runat="server" id="dnnNAV" ProviderName="DNNMenuNavigationProvider" IndicateChildren="false" ControlOrientation="Horizontal" CSSControl="mainMenu" />
becomes
<dnn:RADMENU runat="server" id="dnnRADMENU" MaxLevel="2" EnablePageIcons="False" PagesToExclude="" ShowPath="True" />
Step 2 - Remove the actions and visibility modules.
<dnn:ACTIONS runat="server" id="dnnACTIONS" ProviderName="DNNMenuNavigationProvider" ExpandDepth="1" PopulateNodesFromClient="True" />
<dnn:VISIBILITY runat="server" id="dnnVISIBILITY" minicon="images/DNN-minus.gif" maxicon="images/DNN-plus.gif" />
Step 3 - Download the DNN source and make two changes in the LibraryUI\Utilities\ClientAPI.vb file.
Line 155:
DotNetNuke.UI.Utilities.ClientAPI.RegisterClientReference(objButton.Page, DotNetNuke.UI.Utilities.ClientAPI.ClientNamespaceReferences.dnn_dom)
becomes
If Not objButton.Page.IsPostBack Then
DotNetNuke.UI.Utilities.ClientAPI.RegisterClientReference(objButton.Page, DotNetNuke.UI.Utilities.ClientAPI.ClientNamespaceReferences.dnn_dom)
End If
Line 355:
ClientAPI.GetCallbackEventReference(objPage, "", "", "", "")
becomes
If Not objPage.IsPostBack Then
ClientAPI.GetCallbackEventReference(objPage, "", "", "", "")
End If
Step 4 - compile the Dot Net Nuke library.
Note: Also make sure you are not logged in as an admin or host, as the admin/host panel at the top of the page will also break if you attempt to postback with javascript disabled.
Hope this helps someone else. If you feel like I'm missing some important details, let me know and I'll try and fill in what's needed.
DotNetNuke relies heavily on JavaScript and I doubt there is a real easy way around it - at least considering you need to support all functionality. Perhaps you can clarify that?
The the bottom line here is that you're going to need to modify DotNetNuke to meet your needs. It certainly isn't impossible to get it working, but I would venture a guess that it just plain isn't worth it for most people.
If, as you said, you need to retain ALL functionality without using JavaScript, you're going to have a pretty substantial amount of work to do.
I'd suggest, to get started, you download the source package, set up a development environment on your local machine, turn off JavaScript in your browser and start taking notes. This will help to determine the level of effort involved.
I'm guessing you won't get a lot of responses out of this one (as the poster in the forum thread you linked to didn't) as very few people have sat down in front of DotNetNuke with this as a requirement.
Also, keep in mind that any time you're making substantial changes to the DotNetNuke framework, you're interfering with your ability to easily perform upgrades in the future. Just another thing to think about.
I believe that I've seen the leadership in DNN say that they've taken a hard dependency on JavaScript, and have no intention at this time of considering a non-JavaScript compatible scenario.
That being said, being able to do a simple postback shouldn't be too difficult to support. I would look around in the Client API area for the error that you're describing. A lot of the Client API code is in the DotNetNuke.WebUtility assembly, which is a separate download from CodePlex to get the source.