User interface lags severely on my 2.2GHz mbook pro 3,1

I usually run my laptop just plugged in without battery ever since i had my first battery totally fry on me within 6 months of usage. And i needed to use my computer intensively the last few days so i plugged the battery in reset the computer reset power management controller and started working. Directly after bootup the computer runs fine and fast but shortly after the interface lags greatly. Scrolling in safari becomes painfull, mouse movements not as smooth, and response time to lots of things are ridiculous. Wanted to figure out what was going on. So i downloaded xbench and ran some tests, everything seems normal except for user interface tests.
Directly after boot i would get a score of 130
after some time when i notice it's not working well it drops to 11-15
what could this be? I heard from some other posts it could be skype, i never launched skype still same thing. Activity monitor reports nothing unusual.
Please help. This is ridiculous. I couldn't even use aperture when touching up a photo i took for a billboard ad.

As Allan says, Rani, running without the battery will indeed slow down your processor, which puts it at something of a handicap right from the start.
It sounds as if something else may be adding to this lag, though. You say that Activity Monitor reports nothing unusual. Does this apply to both CPU and RAM usage? When the problem is occurring what sort of CPU percentage is being reported for the most "CPU hungry" processes? What about the "Page ins / page outs" when you look at "System memory"?
How full is your HD? If it is , say, less than about 20% free then it is quite possible that you are suffering from a lot of free space fragmentation. Aperture is one application which can add to fragmentation effects , too.
As far as Aperture goes, have you tried rebuilding the Aperture database files?
How about corrupt or duplicated fonts? It may be that the slowdown is occuring after an attempt to access such an item in one program or another. Check for corrupt or duplicated fonts with Font Book , and get rid of any that it reports.
Have you booted up from your OS DVD and run Disk Utility to "repair disk" recently? If not give it a try. It is not uncommon for some directory corruption to build up over time. Alternatively you could try a "Safe Boot", though it won't directly provide you with as much information as using Disk Utility. (see http://support.apple.com/kb/TS1417 for a description of various options for directory repair).
You might also want to check your HD with Smart Utility.
Cheers
Rod

Similar Messages

User Interface Lag During Medium to Medium-High CPU Usage?

I experience a huge slowdown in UI responsiveness when I do things in the background like unzip a large file. For instance, flipping (Apple - Tab) to an already running version of Safari while unzipping a file takes about 5-7 seconds. I also have a 3.0 GHz Dual Xeon Dell PowerEdge1800 that does the same thing running Ubuntu.
Looking at the CPU activity, this UI slowdown tends to happen when the first core is around 40 % and the second core is a little less than that. The CPU is not pegged but the user interface responds like it is.
Am I experiencing a negative side-effect of dual cure / dual CPU architecture? (Sounds like a budding conspiracy theory doesn’t it?) Or is this due to the unzip process hogging all available disk read/write bandwidth causing disk access starvation to other processes?
--> Or do I need to reduce my caffeine intake?
Thanks,
-Craig
MacBook Pro 2.0 GHz Mac OS X (10.4.5)

Wow. Good to know others noticed this.
After I posted the question I realized it could also be and most likely is a RAM issue.
Thanks,
-Craig

Safari graphical user interface poor quality on Macbook Pro Retina

I’ve noticed that the Safari graphical user interface quality is not good on my Macbook Pro Retina display. Although it has been optimized for Retina displays I keep seeing strange artifacts or glitches from time to time, while this one is persistent, check out the dark stripe behind the bookmarks toolbar : https://www.dropbox.com/s/pa7zizpbi7vdx41/Screen%20Shot%202013-04-21%20at%2012.5 6.11%20PM.png (if the link doesn’t open on click just do the right click - open in new tab) There are also same “spots” on toolbar buttons (bookmark folders) as well, but they are a bit harder to discern.
I don’t think it is a graphic card or display issue since almost all of retina-ready apps work just fine (I have replaced my LG with a Samsung screen, btw).
I wonder does anybody have the same experience with Safari? And if so, has anyone managed to solve the issue?

Try creating a brand new account (in System Preferences -> Users & Groups) and test there.
Tried. The same.
I don't actually have a retina machine, but I see no reason for this to be related to the fact that you have a retina MBP. Unless you have information that suggests it is present on other similar machines...?
At first I thought that it was just on the Retina, but then I really looked into my external monitor and saw it — looking at it right now. It seems to me that when Always show tab bar is ON the space between Bookmarks bar and the tab is sloppy sliced.
The hDPI screen reveals the graphic irregularities from regular DPI screens without a problem.
The reason I posted this here is because I saw many people are having glitches, artifacts and flickers with Safari (on Retina).

Why do I get -18001 Errors using Customised TestStand User Interface

Hi all
I have a problem when attempting to run my application on my host NT PC. I have a customised operator interface to TestStand written using Labview 5.1.1 and built using the LabVIEW application builder. I am running the TestStand Development (Run-Time) System on my host PC.
The problem is that as soon as I go to run my sequence of vis (mass compiled using the same version of LabVIEW and assembled for run-time distribution) I receive the error '-18001 VI Not Executable.'
I think this is probably to do with how I've included the ActiveX server in my LabVIEW User Interface application, but knowing very little about ActiveX I'm not sure exactly what the problem is.
If anyone
has any ideas, I would be extremely grateful for any assistance you could offer. My TS version is 1.0.1
Thanks
Dave

David,
I would like to add to Richard's input. The typical reasons a VI cannot be executed that cause this message are:
1) There is an error in the VI such that the run arrow of the VI is broken when the VI is open in the LV development environment. This problem is usually easy to debug because you should get the error (shown below) when running your sequence in the sequence editor using the default "LabVIEW" ActiveX server provided by the LV development environment (not the LV ActiveX server provided by your operator interface which is by default named "TestStandLVGUIRTS" ).
An error occurred in the 'MyVIStep' step of the 'MainSequence' sequence in 'MySequence.seq'.
LabVIEW : VI is not executable.
An error occurred accessing the LabVIEW ActiveX automation server. Error Code: -18001
2) The same error will occur when
a. you are using any LV ActiveX server other than the "LabVIEW" server provided by the LV development environment, AND
b. at least one of the called VI was not assembled for distribution properly. This means that not all test VIs and their *entire* hierarchy were distributed.
I am not sure exactly what you have done so have compiled some information that I think will help. Below I have included the document, Overview of Distributing TestStand when your Sequences use the LV Standard Prototype Adapter, which will appear in the NIDZ shortly. Another useful document is the NIDZ document Distributing LabVIEW Test VIs, which you can obtain from our website. Read these documents before preceding with the steps immediately below, which give you an example process for distributing. This may help provide a better understanding and guidance in the distribution process. We are working to simplify this process in future versions of TestStand.
For the following example distribution I recommend that you are use default shipping code so that the problem is not complicated with potential errors added through customizations you have made.
Building The Operator Interface
The following are steps if you are using a LabVIEW operator interface.
1) Copy the contents of \OperatorInterfaces\NI\LV to \OperatorInterfaces\User\LV.
2) Open a new VI in LabVIEW. Make sure all other VIs are closed.
3) In LabVIEW Select Tools>>Build Application or Shared Library
4) In the builder click the Load button and load \OperatorInterfaces\User\LV\testexec.bld. This build script is configured to create testexec.exe that contains the LV ActiveX server with the name of TestStandLVGUIRTS (see the Application tab of the builder).
5) In the builder click Build.
6) Once the application testexec.exe is built, run it once so that the server TestStandLVGUIRTS is automatically registered. You do not need to run a sequence. Close texec.exe.
Creating a LabVIEW Run-time Server
If you are using the LabVIEW operator interface then skip this section. The following steps are meant for those who use an operator interface written in a ADE other than LabVIEW. They provide you with a LabVIEW run-time server that is used by TS to run your VIs.
1) Copy the contents of \Components\NI\RuntimeServers to \Components\User\RuntimeServers.
2) Open a new VI in LabVIEW. Make sure all other VIs are closed.
3) In LabVIEW Select Tools>>Build Application or Shared Library
4) In the builder click the Load button and load \Components\User\RuntimeServers\LabVIEW\TestStandLVRTS.bld. This build script is configured to create TestStandLVRTS.exe that contains the LV ActiveX server with the name of TestStandLVRTS (see the Application tab of the builder).
5) In the builder click Build.
6) Once the application TestStandLVRTS.exe is built, run it once so that the server TestStandLVRTS is automatically registered on your development machine. Close TestStandLVRTS.exe.
Assembling the Test VIs for Run-Time Distribution
This distribution process uses one of the shipping TS examples that calls LV VIs.
1) From LV mass compile all VIs in the directory \Examples\AccessingArrays\UsingLabVIEW\. Please make sure that there were no error messages in the Status tab of the Mass Compile dialog box.
2) In the sequence editor open \Examples\AccessingArrays\UsingLabVIEW\AccessingArrays.seq
3) Confirm that the sequence runs without problem.
4) In the sequence editor select Tools>>Assemble Test VIs for Run-time Distribution.
5) If you are using TestStand 2.0 select \Examples\AccessingArrays\UsingLabVIEW\AccessingArrays.seq as the file from which the VIs should be assembled.
6) Set the target directory to be something distinct like C:\temp\AssblVIs.
7) If you are using TestStand 2.0 skip adding Dynamic VIs
8) Save with or without diagrams. Its your choice.
Change Search Directories
Once the VIs are assembled successfully, you must add the new target directory to the TS search directories.
1) In the sequence editor select Configure>>Search Directories.
2) Add your target search directory (e.g. C:\temp\AssblVIs) to the search directories.
3) Close the Edit Search Directories dialog box.
4) Confirm that your sequence steps now reference the assembled VIs. Right click on a step in the sequence and select Specify Module.
5) The dialog should show that the code module is found in the target directory (e.g. C:\temp\AssblVIs) that you just added to the search directories.
6) Run the sequence. This is the initial test to see if the VIs are assembled properly.
Switch the LV Adapter to use the TestStandLVRTS server or TestStandLVGUIRTS
1) In the sequence editor select Configure>>Adpaters.
2) In the Configurable Adapters control select the LabVIEW Standard Prototype Adapter and then click the Configure button.
3a) If you are not using the LV operator interface then switch the ActiveX server to TestStandLVRTS.
3b)If you are using the LV operator interface then switch the ActiveX server to TestStandLVGUIRTS.
4) Close the adapter configuration dialog boxes. You will get a couple of questions boxes. Just click OK each time.
5) Now run your sequence. If successful you are no longer using the LV development environment to run your VIs. This shows that the VIs were assembled correctly, the LV ActiveX server is working properly and that the search directories are configured properly.
You can now try and run the sequence using your operator interface on you development computer. If this test works it means that you have also confirmed that your operator interface is working correctly with all the other components. Now it is just a matter of moving all the component correctly to the target machine.
Distributing Components
-To distribute your operator interface use the distribution tool of the application development environment (ADE) in which you built your operator interface.
-To distribute the TS engine using the Run Engine Installation Wizard tool. This tool is typically not used for distributing your sequences and VIs, which you will probably distribute more frequently than the TS engine. It does distribute and register your LV run-time server (if you are using one) as long as you have stored it in \Components\User\RuntimeServers. It also distributes other TS components that you have stored under the directory \Components\User\.
-You can use whatever distribution system you like to distribute your VIs and sequence files (e.g. ZIP and network transfer are popular) . Ensure that you distribute the assembled VIs and not the development VIs. Also ensure that the location of the VIs on the target machine is one of the TS search directories.
Hope this helps.
Regards,
Kitt
=========================================
Title:
Overview of Distributing TestStand when your Sequences use the LV Standard Prototype Adapter
The general outline of the components to be distributed and the actions to take are followed by a more detailed description.
Components that need to be distributed:
TS engine
Operator interface
LabVIEW executable that will act as a LabVIEW ActiveX automation server (If the operator interfaces is written in LabVIEW, it can function as the LabVIEW ActiveX automation server.).
LabVIEW run-time engine
LabVIEW test VIs
Test sequence files
Actions before distributing:
It is recommended that you test the distribution components on the development machine before you distribute them to your target machine. In this manner you can more easily debug errors that you may encounter
Create the executable that will serve as your LabVIEW ActiveX server on the target machine (components 2 or 3 above).
Assemble the test VIs for distribution.
Update the TestStand search directories so that the sequences reference the assembled VIs.
Configure the LabVIEW Standard Prototype Adapter to use the LabVIEW ActiveX server that you will install on the target machine.
Test the distribution components on the development machine.
Enter section headings, separating each section with a line break:
TS Engine Component
Operator Interface Component
LabVIEW ActiveX Server
Configuring the LabVIEW Standard Prototype Adapter
LabVIEW Run-time Engine Component
Assembling your Test VIs for Distribution
Note
TS Engine Component
With any TestStand distribution you must install the TestStand runtime engine on the target machine. The Run Engine Installation Wizard tool, found under Tools menu of the Sequence Editor, facilitates this process. The wizard tool will create two files, SetupTSEngine.exe and TSEngine.cab. Move the two files to your target machine and run SetupTSEngine.exe to install the TestStand engine.
These installation files include the current configuration settings that exist in the Sequence Editor at the time the tool is invoked. It also includes all process models, TestStand types and step type modules. If you have customized components of TestStand and saved them under the directory TestStand\Components\User, then the components will also be included with the engine installation.
You must purchase at least a base deployment or debug deployment license for each machine on which you install the TestStand engine.
Operator Interface Component
You will also need to install an operator interface executable on the target machine. This program acts as a client to the TS runtime engine, controlling the execution of sequences and displaying their progress. TestStand ships with several versions of TestStand operator interfaces, which are written in different application development environments (ADE). For distributing the operator interface executable, refer to the application development environment in which it was created.
LabVIEW ActiveX Server
You must have a LabVIEW ActiveX server on the target machine. TestStand uses the LabVIEW ActiveX server to run VIs using either the LabVIEW development environment or the LabVIEW runtime engine. The LabVIEW ActiveX server is provided by either LabVIEW development environment or by any LabVIEW executable that has been built with �Enable ActiveX Server� selected. This setting can be accessed in the LabVIEW Application Builder during the build process. When this preference is enabled, you must enter a server name. You will use the server name to configure the LabVIEW Standard Prototype adapter in TestStand.
If your operator interface is written in LabVIEW, then it can act as the LabVIEW ActiveX server on your target machine. TestStand ships with two operator interfaces written in LabVIEW. The standard LabVIEW operator interface is located in TestStand\OperatorInterfaces\NI\LV, while a simplified version is located in TestStand\Examples\OperatorInterfaces\Simple LV. LabVIEW buildscripts are provided for these applications to facilitate building an operator interface in the latest version of LabVIEW. The settings of these buildscripts are such that the applications are LabVIEW ActiveX servers with the server names of TestStandLVGUIRTS for the standard operator interface, and TestStandSimpleLVGUIRTS for the simple operator interface. The applications register the servers the first time they are executed. If you want to manually register or unregister one of the servers, you can invoke the executable with the /RegServer and /UnregServer command-line arguments respectively.
If your operator interface is programmed in a language other than LabVIEW, then you will need a separate LabVIEW executable to provide the LabVIEW ActiveX server on your target machine. For this purpose, TestStand ships with a LabVIEW run-time server application located in TestStand\Components\NI\RuntimeServers\LabVIEW. A LabVIEW buildscript is provided for this application to facilitate building a run-time server in the latest version of LabVIEW. The settings of this buildscript are such that the application is a LabVIEW ActiveX server with the server name of TestStandLVRTS.
Note: When an ActiveX executable server is accessed, the executable is launched automatically if it is not already executing.
Configuring the LabVIEW Standard Prototype Adapter
When TestStand runs a VI using the LabVIEW Standard Prototype adapter, it does so using a LabVIEW ActiveX server. By default the adapter is configured to use the �LabVIEW� server, which is provided by the LabVIEW development environment. If you do not have the LabVIEW development environment on your target machine then you must configure the LabVIEW Standard Prototype adapter within TestStand to use a different server (e.g. TestStandLVGUIRTS, TestStandLVRTS, or TestStandSimpleLVGUIRTS).
To configure your LabVIEW Standard Prototype adapter, select Configure>>Adapters from the menu. In the Adapter Configuration dialog box that appears, select the LabVIEW Standard Prototype Adapter in the Configurable Adapters section. Click the Configure button. You can select or type a server name in the Select or Type Which LabVIEW ActiveX Server to User control. If your server name is not in the list you will need to type it.
As explained in the LabVIEW ActiveX Server section above, TestStand ships with LabVIEW buildscripts to build a LabVIEW operator interface and a LabVIEW run-time server application. These applications are LabVIEW ActiveX servers with server names TestStandLVGUIRTS and TestStandLVGRTS, respectively. You can configure you LabVIEW Standard Prototype adapter to use one of these servers.
LabVIEW Run-time Engine Component
If any of your sequence steps use the LabVIEW adapter or if your operator interface is written in LabVIEW, then you must install the LabVIEW runtime engine on the target machine. It is important that your LabVIEW run-time engine is the same version as the VIs that TestStand executes.
You can find installation files for the LABVIEW 5.1 run-time engine in the LabVIEW installation directory, Labview\APPLIBS\installs\RunTime. In addition, you can choose to automatically distribute and install the LabVIEW run-time engine with the distribution of a LabVIEW executable. Refer to LabVIEW documentation.
Assembling your Test VIs for Distribution
After distributing TestStand, you must ensure that your sequences are able to locate the VIs they call, and the VIs must be able to locate their required resources.
One common mistake is to simply copy the original VIs from the development machine to the target machine. Once you have configured your LabVIEW Standard Prototype adapter to use a LabVIEW ActiveX server other than LabVIEW, your sequence will not be able to execute your original test VIs that your sequences call.
TestStand provides the Assemble Test VIs for Distribution tool, which gathers test VIs and their required resources, and places them in a common location for distribution. You can then modify your TestStand search directories so that your sequences reference the assembled VIs. These topics are covered in the NIDZ document Distributing LabVIEW Test VIs.
Links: See Distributing LabVIEW Test VIs below
Note
Remember to test your distribution components on your TestStand development system before distributing TestStand. If the execution does not work on the development system it is not going to work on your target machine. On your development machine you have more ability to debug problems you may encounter.
Note: One common problem of testing distribution components on your TestStand development system is that your sequences reference the original Test VIs instead of the assembled test VIs. Refer to the NIDZ document Distributing LabVIEW Test VIs for assistance.
Once the components work on your development machine, you are ready to install them on your target machine. The order in which you install these components on the target machine is irrelevant.
==============================================

No Plug-In specified and not allowed to bring up user interface

Hello,
We have several users here getting an error when trying to sign a pdf with Adobe's digital signature. When they click in the field box to sign the document they are getting the following error,"No plug-in specified and not allowed to bring up user interface for selection." We are using Adobe acrobat 9 standard with the latest updates. I have done a total uninstall and reinstall and recreated the digital signature and still the error persists. I have gone as far as renaming the windows profile and nothing seems to work. Any thoughts?
Aaron

A signature field may have associated so-called "seed values" that specify certain signature properties and restrictions. The document's author can associate "seed values" with an unsigned signature field. One of the "seed values" specifies which external signature plug-in must be used to sign this signature field. If you do not have the required plug-in in the Acrobat installation then you cannot sign this signature field. This is the most likely reason that you get this error message. In some environments this is done to restrict the signing to only signing credentials that reside on hardware modules or signing pads. There might be other reason why the document's author chose to put in this restriction.
Contact the author of the document you are trying to sign and find out whether this is the case and if it is then which plug-in you need and where you get it from.

How Do I Reset Indicators in User Interface?

I have a VI that has got out of control. I have created several test sequences that were developed, proven and built into individual VIs. I created a Main VI and placed (cut and paste) each invidual test VI into a sequencial Frame. Long story short; The main screen looks good, but the test values and status indicators do not reset everytime the test is initiated (there is no loop).
Question- How do I reset each of my indicators on my user interface when the test completes?
Thanks in advance,
Rick Horwitz

Try the following: Got to "VI properties...execution". Now place a checkmark for "Clear indicators when called". That might be enough.
(If you are looking for a programmatic solution create an invoke node in the first or last frame as desired, wire it to a reference to the current VI and select method "renintialize all to defaults".)
LabVIEW Champion . Do more with less code and in less time .

How to avoid long user interface response time in long measurements ?

Hi
I tried to find more information regarding techniques how to avoid long user interface response times in case of extremely long measurement times with an external instrument communicating over GPIB, so I post this hoping to get some hint or a link to a guideline. I guess this is quite normal problem.
Problem is that when I want to measure long time in order to get an average result from the instrument, I have to wait until the result is returned from the instrument. Obviously that makes the user interface response very slow in traditional technique.
My restriction is the old GPIB 488 instrument driver that I would not want to modify, but I have source code to it.
What would be the best way to improve the response time for user interface ? I have looked into the few things:
* multithreading
* callback in main program for GPIB events
* modifying instrument driver e.g. to support VISA and creating a VISA callback
regards,
Petri

Several ways to do this:
If you're getting several measurements, you could have the instrument generate an asynchronous interrupt (an "SRQ" in GPIB terms), then collect the data in response to the SRQ callback. While you're waiting for the SRQ's, you can have your main thread running the interface so responsive GUI. You don't have to spinlock on the GPIB read waiting for instrument data.
Or, as you mentioned, you could spawn a thread to manage the measurements, and use a timer in the main thread to periodically allow you to check the status of the measurement thread. Again, the main thread mostly just runs the user interface.
Either way, the idea is to keep the main thread freed up most of the time to run the GUI, and have it periodically check for completion of your measurement sequence. While you're waiting in the main thread, you may want to make sure the user can't inadvertently re-trigger another measurement sequence until the active one is complete.
If you do find yourself doing a dead wait, you'd want to break this up into a series of shorter waits, and in between each wait, do a ProcessSystemEvents from the main thread to keep the GUI active.
Menchar

'Design Patterns' for Application User Interfaces

I'm currently trying to unstick an architectural mess centred around a relatively simple user interface. The problem is thus:
The application has a number of toolbar buttons and menus, some of which require a specific frame or class of frame to be enabled. Some conditions are quite simple, others more complicated.
(Without going into any more detail, it should be possible to appreciate that this is a fairly common problem.)
For this application, I've created a large listener that accepts events from all over the program, converting them into state changes for UI controls. It feels messy, and (although it isn't finished) I suspect it'll be rather fragile.
JBuilder 4 does it by constant querying of application state - but this results in excessive CPU usage and apparant lag.
TogetherJ does it for menus by checking state immediately before showing the menu. This seemed like a good plan, but it's unsuitable for the Action/Button/MenuItem lashup I like to use.
My question is this:
In your opinion, how should an application be structured to reliably maintain the correct UI state at all times?

Check out the mediator pattern. It is pretty close to what you are describing, maybe the details you dig up on it will give you some new ideas?

User Interfaces: Is the ain~ui~mobile Package in AII 2.1 still available?

Hello!
During my studies on the outbound scenario script, I found out that there must exist an ainuimobile WebDynPro application for tagging and packing via mobile reader.
This application is mentioned nowhere in the documentation. Just the obviously older process script uses a link to this application. I didn't found an entry for ainuimobile in the Web Dynpro Content Administrator screen. There is just the ainsodesktop package available. When I try the /MobileReaderApplication on the ainuimobile package, I get a lot of errors. Even when I try the /MobileReaderApplication on the ainsodesktop package, I get errors.
My question is: Is the ainuimobile package or something similar in AII 2.1 available? Has it been removed from 2.0 to 2.1? If this ships with AII 2.1, why isn't it installed with the standard installation?
Thanks in advance,
Johannes

Hi Haakon,
single component export/import is only supported for application which are identical on the source and target system. It relies on the fact that other referenced components (for example user interface, templates, ...) use the same IDs on body systems.
Because of the APEX 4.2 upgrade, that's not the case anymore. As part of the upgrade, several new components had to be created on the fly which do now have different IDs on dev and prod. That's why the single component export/import doesn't work anymore.
If the single component export/import is used to patch applications, it's recommended to do a full export of the app on dev and import it into prod after upgrading to a newer version of APEX to make sure that body systems are using the same component IDs. After that your single component deployment should work as before.
Regards
Patrick
My Blog: http://www.inside-oracle-apex.com
APEX Plug-Ins: http://apex.oracle.com/plugins
Twitter: http://www.twitter.com/patrickwolf

Mavericks user interface hangs - any known solutions?

I have a 27" late 2012 iMac with an up-to-date copy of Mavericks (10.9.4.)
Occasionally (as in every couple of weeks) the user interface hangs completely.
The mouse cursor moves, but clicks do not have an effect, and the keyboard is ignored.
Applications continue to update the screen. Today, for example, I was running Windows RDC 8 through a VPN to a customer server. After the hang started, I could see the progress updates on an SQL server restore as it continued to run. Activity Monitor was updating in the background too.
Connecting from my (17" MacBook Pro) laptop (: I love that machine!) using Screen Sharing worked but I could not update.
I took the dog for a walk for an hour or so, and when I returned there was a login screen on the iMac. To my great delight, I typed in my password and logged back in. To my greater disappointment, the UI was still hung and my only recourse was to crash it by holding in the power button until it stopped, then reboot.
The machine has 24GB of RAM and 1.92TB of free disk space. I doubt it is running out of resources. It has no additional displays connected.
The only weirdness is Teleport - which allows me to share the iMac keyboard with the laptop. It is entirely possible Teleport is the culprit, but I am hoping it is not.

These instructions must be carried out as an administrator. If you have only one user account, you are the administrator.
Launch the Console application in any of the following ways:
☞ Enter the first few letters of its name into a Spotlight search. Select it in the results (it should be at the top.)
☞ In the Finder, select Go ▹ Utilities from the menu bar, or press the key combination shift-command-U. The application is in the folder that opens.
☞ Open LaunchPad. Click Utilities, then Console in the icon grid.
Step 1
For this step, the title of the Console window should be All Messages. If it isn't, select
          SYSTEM LOG QUERIES ▹ All Messages
from the log list on the left. If you don't see that list, select
          View ▹ Show Log List
from the menu bar at the top of the screen.
In the top right corner of the Console window, there's a search box labeled Filter. Initially the words "String Matching" are shown in that box. Enter "BOOT_TIME" (without the quotes.)
Each message in the log begins with the date and time when it was entered. Note the timestamps of the BOOT_TIME log messages, which refer to the times when the system was started. Now clear the search box and scroll back in the log to the last boot time when you had the problem. Select the messages logged before the boot, during the time something abnormal was happening. Copy them to the Clipboard by pressing the key combination command-C. Paste into a reply to this message by pressing command-V.
For example, if the system was unresponsive or was failing to shut down for three minutes before you forced a restart, post the messages timestamped within three minutes before the boot time, not after. Please include the BOOT_TIME message at the end of the log extract—not at the beginning.
If there are long runs of repeated messages, please post only one example of each. Don’t post many repetitions of the same message.
When posting a log extract, be selective. A few dozen lines are almost always more than enough.
Some private information, such as your name, may appear in the log. Anonymize before posting.
Please don't indiscriminately dump thousands of lines from the log into this discussion.
Please don't post screenshots of log messages—post the text.
Step 2
In the Console window, select
          DIAGNOSTIC AND USAGE INFORMATION ▹ System Diagnostic Reports
(not Diagnostic and Usage Messages) from the log list on the left. If you don't see that list, select
          View ▹ Show Log List
from the menu bar.
There is a disclosure triangle to the left of the list item. If the triangle is pointing to the right, click it so that it points down. You'll see a list of reports. A crash report has a name that begins with the name of the crashed process and ends in ".crash". A panic report has a name that begins with "Kernel" and ends in ".panic". A shutdown stall report has a name that ends in ".shutdownstall". Select the most recent of each, if any. The contents of the report will appear on the right. Use copy and paste to post the entire contents—the text, not a screenshot. It's possible that none of these reports exists.
I know the report is long, maybe several hundred lines. Please post all of it anyway.
If you don't see any reports listed, but you know there was a crash or panic, you may have chosen Diagnostic and Usage Messages from the log list. Choose DIAGNOSTIC AND USAGE INFORMATION instead.
In the interest of privacy, I suggest that, before posting, you edit out the “Anonymous UUID,” a long string of letters, numbers, and dashes in the header of the report, if it’s present (it may not be.)
Please don’t post other kinds of diagnostic report—they're very long and rarely helpful.

Controling a user interface with extern DLL

Hi,
I am currently developing an application that is based on a graphical interface. I divide my code into multiple DLLs. By going this route, I met several problems. I want to know some facts:
1 - from the DLL can I assign values to textbox, read listbox of the GUI:GetCtrlVal (panelHandle, PANEL_TEXTBOX, val); (the GUI is integrating in the project who call the DLL)
2 - I use global variables "extern int" in my files. h and my functions. How do I change this variable declaration when I migrate to the DLL.
If you have any exemple describing how can i control a GUI with extern DLL.
Thanks

Hey Fishingman,
It looks like this post is very similar to your other post on Application Architecture. If this is the case, let's continue this discussion on this thread so that it is easier to follow for anyone else who may be keeping up with this.
To expand on my original response a little though - if you are just looking to be able to modify the user interface in a dll then take a look at this link. It explains how to set up dll function calls to modify a user interface. Again, I wouldn't suggest building your entire GUI through different dlls but it is definitely possible to modify it within a dll.
Regards,
Trey C.

Using LabView to serial interface my microscope how I make a user interface to make the stage move by pressing buttons?

I have used LabView very little and am trying to write a program to control a microscope. I want to be able to give it commands such as to get the stage to move left, right, forward, back, and return to zero. I'm having trouble implementing the code into my block diagram. I've been reading LabView 8.6 tutorials for a couple of weeks and I'm still learning. What I know that is that I need a event structure inside a while-loop for the user interface but I've been stuck.
Thanks for any help! If you need me to try and provide more information please say so.
Attachments:
Button.vi ‏21 KB

Alright so my serial port code should be inside a while loop unfortunately it doesn't work whenever I enter a command to move the stage. It sits there maybe I'm missing something.
So let me give you an overview to what happens in my code, so the configure serial port is very crucial. The VISA Write writes the bytes to the port. The first VISA Write takes the string to write command. I connected the second VISA write to make it easier whenever I enter a command, the \r will iniate the command as a whole. Example L\r will move the stage to Left once, ending up at VISA Read then closing. All of this found in separate case structures.
Now the user interface to control the the movement of the microscope is one of my issues, making several attempts to make it work yielded no results. My best work not the best but a attempt is attached, also one of the things with this I'm having trouble with is getting the button to talk to the stage. On previous buttons I worked on I could press the button and light up an LED on the front panel, I thought the same principle would relate to the movement of the stage, no such luck.
I hope I cleared up some misconceptions on my part, I appreciate your patience.
Attachments:
OptiScan.vi ‏14 KB

Using Captivate with a localized user interface

Summary:
I'm working on an Adobe Captivate 2 project describing an
application that has been created in several languages.
I'm trying to follow the Captivate 2 help topic "Using Adobe
Captivate with a localized user interface", to create localized
movies for each language, but it does not work as described in the
help topic.
Can anyone help me with this problem, see below "What went
wrong?"
Steps to reproduce:
According to the help topic:
1. Record a source langauge file from the application (in my
case swedish).
2. Export the text captions to a Word document "Export
project captions and closed captions", and translate the text (into
english).
3. Record a new language file from the application, without
any automatically included objects.
4. Import all objects "Import slides/objects from other Adobe
Captivate projects>Objects only" from the source language file
created in step 1.
5. Import the the caption text "Import project captions and
closed captions" from the translated file in step 2.
What went wrong?:
Step 5 does not work, I cannot "Import project captions and
closed captions" into the new language file, the menu text is grey.
Product version:
Product: Adobe Captivate 2
Version: 2.0.0 Build 1177
Platform information:
Hardware: Qbic pc x86
OS Version: XP Professional
RAM: 1014 MB
Color Depth: ?
Display Card: Intel(R) 82865G Graphics Controller
Resolution: 1280 x 1024

Hi TekEl and welcome to our community
For what it's worth, here is how I might try it.
1. Record a project using either language.
2. Perform a "Save As" to a different name.
3. From the new project, export the Captions.
4. Localize as necessary.
5. Import the revised captions into the new project.
I think the trick here is to ensure that you only attempt to
import into the project that created the export.
Cheers... Rick

Has anyone seen the TestStand 3.5 User Interface disappear during testing?

The user interface disappeared while a test sequence was executing. The Windows Task Manager showed LabVIEW (8.2) and TestStand running but nothing was present on the taskbar for TestStand and the window could not be found. This has only happened once but I am being pressed to explain this hence the question.

plf,
By user interface you mean an operator interface?
If this is the case, what operator interface are you using?
Have you seen this several times?
What kind of sequence were you executing?
Regards.
Antonio Lie.

Nokia 9500 - Front User Interface Screwing Up

For some strange reason the graphics on the front user interface on my 9500 get all scrambled up and messed up for no discernable reason. Initially, I thought that the problem was due to a possible low memory level or maybe a software conflict issue. However, I have performed a hard reset on several occassions and have run only the most minimal of applications with zero items added to the phone's memory and I have received the same result. Thankfully, the front interface is the only part of the phone that has given me any probelms. Can anyone out there help??? Please!!!

Send it back, my friend. This seems to be a serious error. My phone did the same. With only a few weeks to run for the warranty to end, I sent my phone to Nokia for repairs. The had to change the phone (I got a new IMEI) which meant that even they could not fix it.

User interface lags severely on my 2.2GHz mbook pro 3,1

Similar Messages

Maybe you are looking for