Build user interfaces

This question was posted in response to the following article: http://help.adobe.com/en_US/flashbuilder/using/WSe4e4b720da9dedb5-1a92eab212e75b9d8b2-7fe7 .html

Hi Mallika,
Why wouldn’t include the design view in FB 4.7? Will it be included later. This was the main reason for using FB so that we can design UI quickly.
thanks
Kevin Languedoc
Sr Analyst/Developer
Analyst senior et Developpeur
Jubilant DraxImage
A Jubilant Life Science Company
16751 TransCanada Hwy
Kirkland, Qc
(514-694-8220 x.2094
[email protected]

Similar Messages

Tutorial on teststand user interface to cvi

I haven't used the CVI to TestSand User Interface since 2004. I've been put on an upgrade project to go from Windows 2000 to Winows 7, TestStand 3.0 to TestStand 2010, and CVI 7 to CVI 2010. Now I have to make the old UI work.
Are there any good tutorials out there on the CVI user interface for TestStand?
More specifically, I'm trying to figure out why the TS_EngineGetResourceString doesn't work now? (more specifically how does TS_EngineGetResourseString work)
Thanks
"Lockheed" Joe
Testing Blog"

Hey Joe,
Here are some great resources for you to check out on building user interfaces. The first link is an example and the second is more of a general discussion on interface development. If the forums ever don't suffice, you may be able to find more information by searching NI's website for 'Cvi User interface TestStand'. Just another great spot to check for answers.
Simple CVI User interface for TestStand
Best Practices for NI TestStand User Interface Development
Hope this helps,
Luke W

Error in report builder wizard user interface

I am getting error 'REP-31954: Error in the Report Builder Chart Wizard user interface'.
The help subsystem states that I should make sure that the Chart Builder Wizard libraries are properly installed.
I am sure they are because all other wizards work fine, along with the Forms, Reports, etc.
I searched using Google and found two messages that indicate this is a bug in the program and not library installation related.
Does anyone know if this is indeed a bug that has not been resolved, or do I need to troubleshoot more on my end.
I re-linked Oracle graphics and checked the env variables, but nothing gets the Chart Wizard to work within Reports or Forms.
Any help/advice would be greatly appreciated.
Thank you.

Hi.
I am running developer 6i on my home machine (with Oracle 8i, v 8.1.7). I am at work at the moment, and I can't recall what the Reports version is. The same error occurs with Forms.
The filename that I downloaded is called 'd2k6irelease2.tar'.
I downloaded the version that is currently on Oracle OTN's download site, so I presume that is the latest version that should contain all patches, updates, etc.
Thank you for responding!

Re:error in report builder wizard user interface

I am getting error 'REP-31954: Error in the Report Builder Chart Wizard user interface'.
The help subsystem states that I should make sure that the Chart Builder Wizard libraries are properly installed. I am sure they are because all other wizards work fine, along with the Forms, Reports, etc. I searched using Google and found two messages that indicate this is a bug in the program and not library installation related. Does anyone know if this is indeed a bug that has not been resolved, or do I need to troubleshoot more on my end. I re-linked Oracle graphics and checked the env variables, but nothing gets the Chart Wizard to work within Reports or Forms. I am running developer 6i on my home machine (with Oracle 8i, v 8.1.7). The same error occurs with Forms. The filename that I downloaded is called 'd2k6irelease2.tar'. I downloaded the version that is currently on Oracle OTN's download site, so I presume that is the latest version that should contain all patches, updates, etc.
Any help/advice would be greatly appreciated.
Thank you for responding!

Hi Adrian,
Got the following when grepped through the web. You can give a try and see whether it works :
1) Open the report in the Builder. In the properties for the graphic image, change to the proper UNIX path. Also, ensure the .ogd file which is referenced is also placed in the proper UNIX directory, so that the new path is reflected accurately.
2) Ensure that your environment have the ORACLE_HOME set properly and then try re-linking with Graphics.
Thanks,
Vinod

Building a simple User Interface

HI,
I'm interested in building a very simple User Interface. All I want to see is a panel with buttons and each button will execute a test sequence file.
1) Is it possible to create such a panel with CVI or LV and then call a sequence file which will be handled by TS?
In that case, I would expect to see TS panels while executing the sequence and once finished (or closed by the user) to come back to the original panel that calls the sequences.
2) is it better to create this panel with TS utility? (I have never done it and suspect it will not be a simple job).
Thanks
Rafi

You can do this in test stand if a simple interface containing just a prompt and buttons will do. In your main sequence, the first step is to create a MessagePopup step. Put a title like "Test Selection". Put a message like "Choose a Test". Label button 1 "test 1". Label button 2 "test 2", and so on. Create a local numerical variable called TestNum. In the post expression section of the first step, add the line Locals.TestNum = Step.Result.ButtonHit. You next step can be a sequence call to the first test sequence. Add a precondition that Locals.TestNum==1. The following steps can all be sequence calls to your other test sequences with preconditions of Locals.TestNum==x, where x is the number corresponding to the button hit in step one. When the selected test sequence is done, the main sequence will be repeated with the message popup asking for a test to run.
- tbob
Inventor of the WORM Global

User interface builder for JSPs?

Hi
Has anyone used a good builder for a web user interface based on JSPs?
Thanks

There is no template for Interactive Reports like for a "normal" report. You need to modify the CSS and supply your own for this to happen.
I believe most things are tagged with #apexir - firebug with Firebox is invaluable. This thread may help:
Re: changing the look and feel of interactive report.

A more successful experiment in creating compositable user interfaces for Config Dialogs

A couple weeks ago I posted an experiment in creating compositable user interfaces using transparent subpanels. The approach might best be described as, "It at least was notable for being novel."
Today, I'm posting another attempt, this one along more traditional lines, and far more successful. Particularly notable: this one can do all the arbitrary composition of the last one AND it solves the TAB order problem.
This solution uses a picture control and renders N copies of a control. When the user tabs to a control or moves the mouse over the control, a real control slides into that position to be able to catch the events (update mouse over draw state, highlight for keyboard focus, handle typing, etc). When the Value Change occurs, a master array of data is updated and the picture control is updated.
This is something that has been attempted in various forms in the past, but there are two aspects of this particular implementation that make it nice:
its programmatic interface for specifying the behavior of the various objects should make it fairly easy for a user of the framework to programmatically generate their dialogs
it handles the TAB problem without flickering, something I haven't seen in other attemps
This idea spawns out of conversation about the previous experiment -- thanks to those of you who posted on various forums, e-mailed me, or, in a couple cases, showed up at my desk. That last one is not something I'm encouraging unless you work at NI... just saying. :-)
Now, this experiement has already yeilded some interesting conversation. We note that as long as controls are instantiated independent of each other -- that is, no property of one control depends upon the property of another control -- this dialog system scales nicely. But in this experiment, I implemented Radio Buttons, which interact with each other -- when one is set True, the others go False. As soon as controls start interacting with each other (such as graying out one control when a checkbox is toggled, or having expandable sections, or really complex cases like updating a graph as some options change, like happens in some Express VI config dialogs) then we start needing ways to refer to the other controls. This rapidly moves us in one of two directions: naming controls or creating references. The naming approach is definitely my preference as it fits better with dataflow and I can do some interesting effects with breaking apart some of the tree. But all of this quickly starts sounding like "Please implement a XAML parser in LabVIEW." For those of you unfamiliar with XAML, in the world of UI design, it might very well be the coolest thing since sliced bread. A XAML string would indeed fit with dataflow, and we could start building that up. I hesitate to head down this road for two reasons. One, as many have noted, there's really not a good XML parsing library written in LabVIEW that can give me a useful DOM tree. Two, that's a huge project and my gut sense is that you'd have to complete a fairly large chunk of it before you'd start seeing any return on investment. But it is worth thinking about -- I might be wrong. Wouldn't be the first time. This code that I've posted today can at least get you started on the generation side if one of you decides to become industrious.
I'm turning my attention away from this project for now... coding in G is lots of fun, and I wish I could spend more days doing it, but this has been a side project and it's time to get back to my assigned projects in text programming. Building a powerful platform for automatic UI generation in LabVIEW would be really useful -- I see lots of requests for this sort of thing, and other languages are pulling ahead of us in this domain.
[UPDATE 5/17/2012 - There is an improved version.]
Solved!
Go to Solution.
Attachments:
ConfighThroughCtrlCreation.zip ‏558 KB

Elijah K wrote:
Thanks for posting this Aristos. I would normally be one of those to go bug you at your desk, but in case I'm not the only one with this question... which particular flickering problem are you referring to? The act of switching tabs? In all honesty, I've never noticed...
When you move controls around on the screen, normally you try to Defer Panel Updates while you do that. But Defer Panel Updates has an effect on control's abilities to catch certain mouse clicks, so when you're trying to move a control to catch the mouse, you have to work a lot without Defer Panel Updates, so if you're adjusting captions, etc, to match the new location, you can see flicker as properties adjust. You can move the control off-screen, as long as you have already updated the picture control to reflect the changes. It took a while to catch all the ways that the flickering can crop up. I think I got 'em all.
Attached are the VIs saved for LV 2009. Actually, they're saved for LV 8.6, but it doesn't work in 8.6 because of a bug in the picture control that existed back then.
Attachments:
ComposableUI_LV2009.zip ‏391 KB

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.
==============================================

FAQ: User Interface Guidelines for CRM 2007 are now available

The CRM UI Concept Team has made the UI Guidelines for CRM Web Client User Interface (CRM 2007 UI) available to the BPX community:
This document provides an overview of the on-premise as well as the off-premise versions of the SAP CRM Web Client User Interface (UI). It contains the properties and principles of the SAP CRM Web Client UI that are already committed and available. For planned features, refer to the corresponding specification documents.
The information in the guidelines starts with general topics, followed by details. The sections are organized with high-level topics like Page Types and Navigation Schema first, followed by the consecutive sections describing which building blocks and elements of the UI populate the various pages. A section typically starts with one or more screenshots of a central UI element with a generic explanation. The subsequent sections explain the detailed aspects of each element.
We hope that you will find this information useful.
Enjoy the new CRM UI! [UI Guidelines for CRM Web Client User Interface (CRM 2007 UI)_ |http://www.sapdesignguild.org/resources/CRM-UI-Guidelines-Customers.pdf]
Edited by: Zhaojie Liu on Jun 10, 2009 10:08 AM

Hi,
not sure why your download stops.. you can also try to download via this link: [http://www.sapdesignguild.org/resources/CRM-UI-Guidelines-Customers.pdf|http://www.sapdesignguild.org/resources/CRM-UI-Guidelines-Customers.pdf] (Document is 17,4MB of size)
Here the guidelines also have been posted together with an article about the CRM 2007 Web Client UI.
Hope this helps
Best regards
Ingo

User Interface Guidelines for CRM 2007 are now available

The CRM UI Concept Team has made the [UI Guidelines for CRM Web Client User Interface (CRM 2007 UI)|https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/302d8152-002b-2b10-34bd-9ff3c712dd4b] available to the BPX community:
This document provides an overview of the on-premise as well as the off-premise versions of the SAP CRM Web Client User Interface (UI). It contains the properties and principles of the SAP CRM Web Client UI that are already committed and available. For planned features, refer to the corresponding specification documents.
The information in the guidelines starts with general topics, followed by details. The sections are organized with high-level topics like Page Types and Navigation Schema first, followed by the consecutive sections describing which building blocks and elements of the UI populate the various pages. A section typically starts with one or more screenshots of a central UI element with a generic explanation. The subsequent sections explain the detailed aspects of each element.
We hope that you will find this information useful.
Enjoy the new CRM UI!
Feel free to provide your feedback.
Edited by: Florian Weigmann on Jul 17, 2008 9:14 PM

Hi,
not sure why your download stops.. you can also try to download via this link: [http://www.sapdesignguild.org/resources/CRM-UI-Guidelines-Customers.pdf|http://www.sapdesignguild.org/resources/CRM-UI-Guidelines-Customers.pdf] (Document is 17,4MB of size)
Here the guidelines also have been posted together with an article about the CRM 2007 Web Client UI.
Hope this helps
Best regards
Ingo

Failed to call EJB from Managed Bean in user interface

Hi,
I'm very new to JDeveloper and EJB. I'm now in learning stage. I managed to find a simple example for me to get started. But I encountered errors.
This is the tutorial that I have followed -> http://www.packtpub.com/article/Building-JSF-EJB3-Applications
When we create an application, the application will consist of EJBModel and Interface (JSF View)
In my EJB Model, I have session bean name myappejb.ejb.QuestionSessionBean and one Entity bean name myappejb.entities.Question
In my User Interface, I have created a managed bean name QuestionController and I try to call QuestionSessionLocal in the EJBModel, but before I can compile, there are systaxs errors. I can't import the import javax.ejb.EJB and myappejb.ejb.QuestionSessionBean, stated not found. In other words I can't call all the beans that I have created in EJBModel from java class that I have ceated in UserInterface.
Please advise, I'm lost.
WenXin
I really confuse how exactly it works
Edited by: user8989450 on Jan 14, 2010 12:57 AM

Hi,
The problem has been solved. I found the solution, this is due to the "dependencies", must "Checked" the EJBModel.jpr.
Thanks.
Wen Xin

How to get to learn using TestStand User Interfaces

I am starting to work with TestStand and I was looking into using the User Interface. I know that a couple of examples are provided and that there is a couple of sections of literature on the subject, but there does not appear to be a very helpful (get started from scratch) type of documentation that I can find. Does such a thing exist? If not, what is the best way to get started?
Solved!
Go to Solution.

You can currently do this in the Full-Featured UI without any modifications. It's kind of a hack though:
So assume that an execution is running. The user clicks the Break button and wants to rerun a step with different parameters. So now your execution is paused somewhere below the step. Right click the step and select: Set Next Step to Cursor. Now in the Variable window look for the variable that is being passed as a parameter to that step. Say for instance Locals.Foo is being passed to your VI. Change the value of it and click the Resume button. This also assumes that you are passing either Locals or FileGlobals to your VI. You may have to have Administrator privileges to do this.
If this isn't good enough then there are ways to accomplish what you want in a cleaner manner.
One way is to build your sequence file such that if a certain condition occurs then retry with new values or values from a file which can be changed by the user. This is what I would recommend because it will be the cleanest and the easiest.
Another way is to build into your UI like you are asking about. The problem with this is at a certain point the user will click Break or a Stop button that you have put on there. This will stop the execution at some point (who knows exactly what point unless you write code to specify a point). Then they would have a pop up or something that would allow them to select a step. Then for each step you'll have to have some code or a parser or something that will determine the parameters and valid values they can be and ask the user for those. This is all doable but would be quite a task. You will have a long ways to go in understanding the TestStand API in order to accomplish this. In fact there would be so many API calls with numerous ways to attack this problem.
Whichever way you choose to go you will always have the TestStand forums or NI support.
jigg
CTA, CLA
teststandhelp.com
~Will work for kudos and/or BBQ~

Reading the output values after each step executes in LabVIEW User Interface

Hello all,
Development environment: TestStand 2010 SP1 and LabVIEW 2010 SP1
Problem: is there a way to execute the subsequent steps programatically and get the output values from each of them?
I have already extended a little bit a Full OI interface for TestStand to load up any sequence, choose some of the steps and run them step by step (something like option to Run Selected steps). What I am trying to do is to add some actions between each step and do that in User Interface (I can't modify the sequence!), so I am starting the NewExecution with some previously configured InteractiveArgsParam and set an option breakAtFirstStep to True. Afterwards I am just doing something like Step Over when debugging the sequence and this works good, but I didn't fine a way yet to read the output values from the steps...
Then, if I wait until the execution finishes I can read my Results by processing the ResultObject, but this works only after finalizing of the test sequence. Since I wanted to stop after each step, read the values, do some actions and continue to the next step I tried to register an event callback for Trace of Execution View Manager. I can see that after each executed step this event is triggered, but when I try to read a ResultObject returned in Event Data it is not filled with values (ResultList seems to be empty?). Is it a proper behaviour or maybe I am doing the readout in wrong way? (It is the same VI as for reading ResultObjects after sequence finishes and there it works fine for arrays, containers and other data types).
Like I mentioned I can't modify the Test sequences, I can't add a UImessages.
What are my options? Should the trace event returns all output values from each steps or is it just used for status checking? Or maybe there is completely different approach to that matter?
Thanks in advance for any suggestions,
Best Regards.
CLA, CTD, CLED @ Test & Measurements Solutions Poland
Solved!
Go to Solution.

Thanks for your replay, I have tried to build it in my LabView Block Diagramm, es seems like this image.
But the variable GetNumSubProperties ist always 0. Why?
PS: I need only the variable "Step.Result.PassFail" from the last step, do you know, how can I get it? I think, it is maybe easier than read all the "Result".
Attachments:
ReadStepResultInLabview.JPG ‏39 KB

Graphic user interfaces

Does oracle olap have graphic user interfaces like SQL Server Analysis Services?

At Escendo we also offer products that have direct access to the OLAP Option including write back. Escendo Analytics, and Architect. Check us out or contact us at http://www.escendo.com
Escendo Analytics*
* Full graphic Calculation builder including support for aggregations, allocations, models and many others even including the standard regression and forecasting, Geneva Forecasting and Monte Carlo simulation.
* Process Management which utilizes DBMS_SCHEDULER making for multiple threaded processes such as as parallel loading/processing a snap - full dependency mapping and approvals and flexible scheduling.
* Direct Read/Write access through our ad-hoc reporting with all the usual slice and dice features you would expect in a flash front end
* User access control and management through our Business Perspectives (users, groups
* Easy sharing and collaboration - use any standard SQL reporting tools against the the same data (obviously since this is an Oracle Forum I must add that OBIEE, Publisher, APEX etc - literally any reporting tool)
Architect* is a multi-simultaneous developer workbench which allows full direct access to the OLAP Option capabilities, while our Analyzer web interface to Analytics provides
*version Control including optional integration with subversion, promotion management (dev->test->QA->PROD for example)
*partition templates
*Fullly automated multi-user access
*both Visible and non-user visible measures
*aggregation and allocation management
*native support for both level and value based(ragged) hierarchies
*model and Program editing with lots of Features for productivity and quality enhancements (we use it to develop our flagship products)
*Conversion utilities for legacy Express Applications (Like OFA) - we have converted OFA systems (including reports and saved selections) with huge performance boosts in under a week.
Don't forget that since we are inside the database with Oracle OLAP, there are huge benefits in managing a truly integrated solution. As part of the database kernel, you have scalability, performance and reliability which is unrivaled. (Things like rman, imp/exp etc.
A partner has an excel add-in which has native support the Escendo application platform. http://myobjectiveolap.com/index.htm It is very useful in that you have very advanced control and interaction with the OLAP option allowing complete control over your excel formatting and layout.
Edited by: user467608 on Jul 8, 2010 7:41 AM

Suitable user interface application for a billing system

I am seeking an appropriate friendly user interface application that is appropriate for a billing system to interact with an oracle 10gr2 database.
Thanks

I'm not sure I understand the question.
If you have a billing system, presumably the billing system has a user interface. It's not like you could just bolt a new user interface over the existing one without a tremendous amount of effort.
Are you looking to purchase a new billing system with a user-friendly interface? If so, it seems odd to post that here. Presumably, you'd want to create an RFP that vendors of billing systems could respond to.
Are you looking to build a new billing system? If so, there are dozens of languages, frameworks, and APIs that could be used. Without more information, no one could possibly provide any useful recommendations.
Justin

Build user interfaces

Similar Messages

Maybe you are looking for