I have a project that provides a JS API for (long running) user scripts.
This project still uses the QtScript module which is kinda bugging me since the module is labeled deprecated for quite some time.
My problem is that i need the users to be able to debug their JS code, which is where QtScript and especially QScriptEngineDebugger is really handy.
Now i just read those 2 lines on the "What's New in Qt 5.7" help page.
Enabled all debug services to work with QJSEngine (instead of QQmlEngine), which allows non-QML JavaScript debugging or profiling.
Added support for debugging multiple QJSEngine instances at the same time.
Obviously that caught my eye, but searching through the rest of the help i couldn't find anything about debugging QJSEngine.
Can anyone tell me how to achieve something similar to QtScript and QScriptEngineDebugger with QJSEngine?
Related
I want to develop Document Manager application based on Alfresco. I am going to change there many things: user interface, language, may be some functions... But I don't know how to start, where I can get Alfresco source code, how can I rewrite codes with netBeans and how can I test my changes. This is my first serious project so I need any help. Where I can get Started ?!
A very popular way to get started is to work through my tutorials.
You don't need the source code, although it is available and helpful when you are troubleshooting or learning how something works. Instead of forking Alfresco you will write extensions that customize the platform. If you find yourself needing to compile Alfresco's source code, most likely you are doing something wrong.
I have searched the internet for 2 days having found no answer to the below requirement. What i found most were GeckoFX and CefSharp which are external packages and not installed libraries. How can this be done?
I have been asked to do the following:
Use a suitable library function out of the set of libraries installed with the .NET platform. You must not use the C# WebBrowser class but perform the required HTTP-level communication directly from within your code. The code must clearly identify the HTTP-level client-server communication and must explicitly manage Home page, Favourite, History Lists and Tabs.
Optionally, you may add functionality to render a web page, but there must be an option to disable this functionality and to show only the raw HTML that has been retrieved.
Thanks
What have you attempted so far and what problem are you encountering?
Maybe read this first :)
Currently it sounds like you have been given an interview or homework task that you dont know how to solve. If so, then you should have some idea on where to start or you are in the wrong course or job interview. If you want help, then try to solve the question yourself and ask for help when you are stuck. Tell us what you have tried, show the code you currently have and let us know where you are stuck or what doesnt work as expected.
Where are you stuck? Fetching the webpage? Building the user interface?
All answers point to "no!". However, some people say having debugging enabled is convenient when errors occur on the server. I am not sure what they mean by this. Do people actually debug live server code? I honestly didn't even know you could. With the website I work on, we use ELMAH for error reporting. When a server error occurs, we are emailed a complete stack trace. After acquiring a rough idea of where and how the error occurred, I will open the local solution containing all the code that's currently deployed to the production environment and debug locally. I never actually debug the code on the server itself, so I am not sure what people mean by that.
I ask this because I just found out today while consolidating web.config XML that debug=true exists on in the staging and production environments' web.config files. It must have been this way for a few years now and I am wondering what benefits we will experience by turning it off. Could anything possibly depend on debugging being turned on that might break if shut off after being enabled for over two years since the beginning of the project?
It should be fine to turn it off, and you should get a slight performance boost. It sounds like you are doing the right thing using ELMAH. I cannot think of a good reason why you would want to have it turned ON in production... hope that helps.
The "advantage" that people are talking about is that when an error occurs on the site, the default asp.net error page will show you the actual line of code that failed. If you have debug=false, then you will not see any of that information. I think most who would recommend something like this either do not know about logging frameworks like ELMAH (and hence, cannot easily find the cause of errors on the site without this), or they have left it on the production machine in the beginning of the project while they are installing/testing the site, and then forgot to change it later.
However, with a proper logging framework in place, you can still get good error information behind the scenes without presenting it to your end-users in that way. In fact, you don't want to show that kind of information to end-users because a) they won't know what it means, and b) it could be a possible security issue if sensitive aspects of your code are shown (info that might help somebody find vulnerabilities).
All the System.Diagnostic library is depend from this flag. If you do not use any of this function, then probably you can not see any direct effect, but for see other effect and messages that come from debug functions you need to monitor at lease the windows log file.
Functions like Debug.Assert, and Debug.Fail are still active if you do not set the debug flag to off, and affect performance, and maybe create small issues that you never see if you do not check the windows system log file.
In our library that they are full with assert, the debug flag are critical.
Also with Debug flag to on, probably the compiler is not make optimization's that also affect performance.
Either an advantage or disadvantage depending on how you look at it is that Webresource.axd type files are not cached when debug="true". You've got the advantage of having the latest files every time and a disadvantage of having the latest files every time.
This is often true with other third party compression/combining type modules due to the fact that it is easier to debug non minified javascript etc so they usually only begin properly function once debug is disabled.
Disclaimer:
This is the first time I am asking a question that might be classified as subjective. As English is not my first language, it is hard to phrase this right. So please feel free to edit the question in order to make it clearer, or to point me at other ways for asking this.
Intro:
David Ebbo (architect on the ASP.NET team) just posted on Register your HTTP modules at runtime without config using the seemingly undocumented PreApplicationStartMethod assembly level attribute
I have mixed feelings about it.
On the one hand it is good to be able to do things as early in the application startup phase as possible.
On the other hand: Does it suffice? Do we need a PrePreApplicationStartMethod allowing to fiddle with the PreApplicationStartMethod behaviour? What about expansion to non-assembly use (for instance, NuGet already works around the single-use-per-assembly restriction of PreApplicationStartMethod)?
Question: Besides using it for config-less startup, what do you think of the PreApplicationStartMethod attribute?
I think one of the good usages for this is that it allows someone who is writing a 3rd party assembly, or a team that is working on an assembly that will be used in many projects, to be able to use this attribute to initialize stuff w/o requiring the end user/developer to create anything in the global.asax in the application startup events.
There are lots of app specific stuff that people like to/need to configure in global.asax, but if you are creating a DLL, you no longer have to make the user configure your classes in the global.asax, you can just put all your logic in your own init/bootstrap function and rely on asp.net to call your init logic when the app starts.
I am trying to create a moderately complex web page. This is not something I have ever done before, and nor do I feel happy about doing it, but I need to do it. I am not asking you to write it for me, mealy tell me what to research and learn, so that I can hopefully, eventually get it done.
I have not got a clue about how to start, and this is my question.
I need to make an autoupdater for my application. This has been done, and it is working perfectly. However, my application currently downloads version.txt, and reads it to work out whether it needs to download the new application. This is hideous, and slow, and was only supposed to be very temporary. It is also very annoying that we have to update this file every time we release a new version.
My boss wants me to create a webpage that reads the version data from the uploaded .exe, and then returns that to the Desktop application. Therefore, I would be able to call www.example.com/version.aspx, and it would return the version number, such as 1.1. I could then compare to the current version (don't worry, it is generated on the fly, and not hard coded) and then I could download the application if required.
Here comes my question. How would I go about this? I have heard of CGI scripts, and asp.net. Which one of these has the power to solve my problem. If you could just tell me that, then I will be all sorted, as I could read up on it, learn, and broaden my knowledge.
If this is not possible, or not easily possible, is there any way of reading the file version of a remote .exe, without downloading it. This would also be preferable in many ways.
Thank you so much, and I am so sorry for my complete ignorance in this topic.
Richard
P.S. I did try to explain this to my boss, and suggested that maybe he could either do it, or help me, but he is not very good at web applications, and refused, saying that it would broaden my education in this matter. Ahhh!
EDIT: Somehow forgot to add: I normally program in C#, although this application should be so small, that it would not really matter. Also, C# code would be ideal, if there is a way to check the version of a file on a remote server.
EDIT: Thanks!
If you can read the version of some exe file from within a desktop application, using C#, then you can use the exact same code to read it from within an ASP.Net web application.
The advantage of asp.net over CGI (in your case) is that you can use C# in the backend.
A couple of hints:
Server.MapPath("file.exe") returns the complete pathname of a "file.exe" next to the requested aspx file, independent of where you install that web-application.
If you only want to return the version number, use
this code:
Response.Clear();
Response.Write(versionnumber);
Response.End();
in a Page_Load method, after you have read the versionnumber of the exe, of course.