The app starts with a blank screen for a while before the app really loads
I'm using electron-forge's react-typescript template.
I can make a dmg or deb file successfully, but I noticed when I run the packaged app, there will be a blank screen for a while before the app actually load especially the first time
I checked the distributable file and found the whole source code inside it, so I guess it's because it has to compile typescript every time?
Then how to "precompile" my source code and use that to make a distributable app?
update:
Since the project was developed by other colleague, I just found out this project is using electron-compile to compile it on the fly, maybe the solution has something to do with this?
I checked the distributable file and found the whole source code inside it, so I guess it's because it has to compile typescript every time?
This is not true. Current stable uses electron-prebuilt-compile (https://github.com/electron-userland/electron-forge/blob/1709af0bc53bd962466dd2025672b95f2e9399cc/packages/api/core/src/util/electron-version.ts#L6) which creates precompiled cache for typescript files for packaging time. Typescript source is only needed for module resolution in actual filesystem.
there will be a blank screen for a while before the app actually load especially the first time
This requires profiling application itself to find out what is happening in meanwhile. It is possible module resolution takes long or either any js execution time's blocking, but can't tell without profiling it.
I would like to stop and start ALTactileGesture service through ServiceManager during my app. I'm using Choregraphe and python boxes. I have tried different options to initiate ServiceManager but none of them works. Is there any way of doing this?
Edit:
I have already tried self.sm = session.service('ServiceManager') but did not work.
The idea is to stop ALTactileGesture as soon as the app has started:
(1) ServiceManager.stopService('ALTactileGesture') (see this)
and start/restart ALTactileGesture before the application ends:
(2) ServiceManager.startService('ALTactileGesture')
My question is how to reach ServiceManager so I can then use (1) and (2)?
You have to understand that the word "service" actually means two different things in NAOqi. See an explanation here:
NAOqi services (also called "modules"), that expose an API and are
registered to the ServiceDirectory. You can call them with qicli,
subscribe to their signals, etc.
systemd services, that are standalone executables packaged in an
Application Package, declared in it's manifest with a tag.
These are managed by ALServiceManager, who can start and stop them
(they will have their own process). For clarity's sake, these are
called "Executables" in this doc.
The confusion between the two is increased by the fact that a common
pattern is to write an executable whose sole purpose is to run a NAOqi
service, and sometimes to identify both with the same name (e.g. both
are called “ALFuchsiaBallTracker”).
Your problem here is that the NAOqi service ALTactileGesture is run by the executable registered under the ID ALTactileGesture-serv. So you need to do
ALServiceManager.stop("ALTactileGesture-serv")
(I just tested it, it works fine)
(edit) by the way, I'm not sure that actually stopping and starting ALTactileGesture is the best way of doing what you're trying to do (it seems a bit hacky to me), but if you want to do it that way, this is how :)
Just try this in robot shell (old style proxy connection):
$ python
import naoqi
s = naoqi.ALProxy("ALServiceManager", "localhost", 9559 )
s.stopService('ALTactileGesture')
>>> False
s.startService('ALTactileGesture')
>>> False # (a bit weird, but ...)
So I think it's not completely working, but at least you can connect to the ServiceManager as requested...
I am currently faced with a dilemma in regards to adding any kind of DLL to a ColdFusion project. I have done a ton of research but nothing seems to be simplistic enough to grasp an understanding. I have a Winform that uses the same DLL in the Reference which makes life easy. When looking to add the same DLLs to a ColdFusion project, it doesn't seem to be working. I have tried using the following:
<cfobject type="com" name="myObj" assembly="C:\DocViewer\AxInterop.SHDocVw.dll">
Here is the error message I am receiving as well:
Attribute validation error for tag CFOBJECT. It has an invalid
attribute combination: assembly,name,type.
This site has been very helpful in the past and I am hoping to learn how this DLL in CF9 works so that I do not have to completely rewrite an entire program when the current one works perfectly.
From comments
I tried adding the DLL using the regsvr32 but here is my error now:
the module was loaded but the entry-point dllregisterserver was not found
Well it looks to me like you're using the cfobject attributes for a .NET object instead of for a COM object. The cfobject tag is one of those tags where the attributes vary by action/type, like cfcontent, cffile and cfdirectory (and a bunch of others that don't immediately spring to mind).
So you need the documentation for accessing COM objects specifically, which for the latest version of Adobe's CFML engine is located here: https://wikidocs.adobe.com/wiki/display/coldfusionen/cfobject%3A+COM+object
There's a typo on the docs page, but it looks like this should work for you (although I'll admit it's been a while since I've invoked a COM object):
<cfobject
type = "com"
class = "path.to.com.Class"
name = "myObj"
action = "create|connect">
It looks like you would use action="connect" if you have it installed as a Windows Service, or create if you want CF to instantiate the DLL, but I would guess having it installed as a service would be easier. I'm just guessing, but I think "path.to.com.Class" would be the name of the service if you're using it that way, or it would be the logical path to the .dll file if the CF server is instantiating it. If neither of those options work, then there might either be a version incompatibility if this is being moved to a newer OS, or the service might be misconfigured.
The error message from registering the DLL sounds like (and I'm guessing because I've never created a windows service DLL) it's looking for a specific class or function in the DLL in order to register it as a service in Windows and it can't find that "entry point" in the DLL (i.e. in the same way that Java will look for a "public static void Main(String args)" as the entry-point to a Java program). That may be necessary for a Service, but it's probably not necessary for a generic DLL that might be accessed and used in some other way, so it's possible this DLL might work, but not be compatible with Service registration.
So going back to your sample code, this might work:
<cfobject type="com" name="myObj" action="create"
class="C:\DocViewer\AxInterop.SHDocVw.dll">
I have a WPF app that uses a non-WPF vendor library. My app does not receive any events that the library fires. I've been told that this is because I need a message pump.
In another (very similar) question, the accepted answer suggested using System.Windows.Threading.Dispatcher.Run().
When I add in that call, however, my window won't pop up-- the app is effectively backgrounded and I have to shut it down with Task Manager.
I'm really stumped here, and I'm not even sure how to investigate it. Any help would be greatly appreciated.
You already have one if you use WPF, there's no other way that it can get any Windows notifications. Every WPF app starts life with a call to Application.Run() on the main thread. It is usually well hidden, auto-generated in the bin\debug\app.g.cs source code file. Application.Run() in turn calls Dispatcher.Run()
Your vendor is correct, without a message loop many COM components go catatonic. But since you have one you need to look for the problem elsewhere. Don't use the component on threads.
What's the best way to determine if the version of the JRE installed on a machine is high enough for the application which the user wants to run? Is there a way of doing it using java-only stuff? I'd like the solution to work on Windows/Linux/MacOSX - if the JRE version is too low a message should be displayed. Currently I'm getting an exception if i try to run it on Java 1.5 (the app is built for Java 1.6). If there's no universal solution, what's the best way to do it on Windows?
You could do this using reflection and two compilers. Compile a main class with the oldest java version you want to be able to run at all with. It checks the version using System.getProperty("java.version"), or whatever, and then uses reflection to load your real main class if that check passes, possibly even loading the jar directly. The JRE shouldn't load any classes that weren't referenced by your outer main class at compile time.
You might consider Java Webstart. Even if the name implies something like applets, it's about standalone-applications. Webstart is a launcher, that checks a JNLP-file (a simple XML-file, where you configure the download-location of your app, the needed Java-version and some other metadata) and starts your app with the correct JRE. It even updates the application, if a newer version is available. The downside is, you have to write a JNLP-file. Here is an example:
<?xml version="1.0" encoding="utf-8"?>
<!--
###############################################################################
#
# #(#)draw.jnlp 1.6 02/09/11
#
# JNLP File for Draw Demo Application
#
###############################################################################
-->
<jnlp spec="0.2 1.0"
codebase="http://java.sun.com/javase/technologies/desktop/javawebstart/apps"
href="draw.jnlp">
<information>
<title>Draw 4 App</title>
<vendor>Sun Microsystems, Inc.</vendor>
<homepage href="http://java.sun.com/javase/technologies/desktop/javawebstart/demos.html"/>
<description>A minimalist drawing application along the lines of Illustrator</description>
<description kind="short">Draw Demo Short Description</description>
<icon href="images/draw.jpg"/>
<offline-allowed/>
</information>
<resources>
<j2se version="1.3+" href="http://java.sun.com/products/autodl/j2se"/>
<j2se version="1.3+"/>
<jar href="draw.jar" main="true" download="eager"/>
</resources>
<application-desc main-class="Draw"/>
</jnlp>
A second possibility is to use a launcher-program. An example is the Apache Commons Launcher. You can also write some launcher app yourself, but that's usually not worth the effort.
You might also consider using Commons-Launcher, which allows you to setup various environment settings, or perform pre-checks before calling your application.
http://commons.apache.org/launcher
Generally, we've approached this with a C or (when unix-only) shell wrapper. Not sure this will really work for you.
We also approach this by embedding the JRE in our product. Takes care of 99.9% of the cases (the other 0.1% of the time is a user explicitly changing our configuration to use a different JVM). Again, not sure that this is a reasonable solution for you.
In our case, there is significant amounts of native code (JNI and otherwise), so tailoring an installable image for each platform we support is required anyway. But if you're dealing with a pure-Java solution, you may simply have to document your minimum and tell people to get with the program (no pun intended) if they're to run your stuff. It's sorta like people complaining that my Mac won't run MSVC, or that my Linux box is having problems running World of Warcraft. That's just not the (virtual) machine the software is targeted for - you need to switch. At least in the Java world, we really can call this an upgrade, though, without hurting anyone's OS-religious feelings. (Try telling the Mac user to "upgrade" to Windows XP to run MSVC - there's a beat-down waiting to happen.)
You can require a Java version when running the Java command, e.g. java -version:1.6* com.me.MyClass. Not sure if this works on all releases of Java, but it works OK on 1.6 anyway.
An application built for a higher-version JRE will not run on a lower-version JRE. So you wouldn't be able to just add code to your application to check the JRE version - if the JRE version was incompatible, your JRE-version-checking code would not run in the first place.
What you'd have to do is have some sort of launcher application that is built for a lower-version JRE (1.3?) that checks the version and then launches your app if necessary. This sounds kind of kludgy to me.
What about checking the version during installation? Are you installing the app in a way that allows you to check environment variables, or do any sort of scripting?
For the launcher - Check the version in there.
Inside the APP; as above use System.getProperties();
Properties sProp = java.lang.System.getProperties();
String sVersion = sProp.getProperty("java.version");
sVersion = sVersion.substring(0, 3);
Float f = Float.valueOf(sVersion);
if (f.floatValue() < (float) 1.4) {
System.out.println("Java version too low ....");
System.exit(1);
}
...
Have a launching class compiled for Java 1.2 which invokes the real main() in your 1.6 classes. If an unsupported class exception is thrown them catch it and display a nice error message.
Here is the code to get the JRE version installed in a system.
var list = deployJava.getJREs();
var result = "";
result = list[0];
for (var i=1; i<list.length; i++)
{
result += ", " + list[i];
}
document.write("jre version : "+result);
System.getProperties() gives you a listing of JVM properties including the different version ids of the JRE, JVM and specification. This implemented for all versions of Java so should work regardless of version compiled in and version run in, or the implementation.
If you write a basic class to test the version, you can call this first in your main() launching class. It must really be basic functionality though or you might risk breaking it.
Hmm .. call me a boring guy, but what's wrong with using Launch4J or any other native launcher, for instance.
Use a native launcher to check the JVM version before actually running your code. Java only solutions (in my book) only make sense when you deal with developers; once you hit end-users, you'll realize that they dont care about Java or its technical details at all. If you would have written your application in GW-Basic they would not care less as long as your application works.
If Java 1.6 is not installed, lauchner4j will point the user to the download page for JDK 1.6. Thats probably more suitable for your problem than doing magic in Java.
I find that WinRun4J works quite well for me (but then again I may be biased since I wrote it:-)). This lets you specify a minimum and/or maximum version of java allowed. It will pop up a message box to the user if a suitable JRE version is not found (and the message is customisable).
All those above is too damn complicated.
Just go:
Properties props = System.getProperties()
props.list(System.out)
And you will see everything about your JVM, JRE, JDK and staff.
Or get a specific value by using:
//full list of possible props you can see if u run code above
String props = System.getProperty(prop)