You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(53) |
Nov
(66) |
Dec
(24) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
(5) |
Mar
(72) |
Apr
(15) |
May
|
Jun
|
Jul
(10) |
Aug
(2) |
Sep
(18) |
Oct
(2) |
Nov
|
Dec
(6) |
2005 |
Jan
(41) |
Feb
(28) |
Mar
(14) |
Apr
(18) |
May
(10) |
Jun
(6) |
Jul
(5) |
Aug
(1) |
Sep
(3) |
Oct
|
Nov
|
Dec
(1) |
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
From: Ton P. <tc...@gm...> - 2011-11-25 06:26:13
|
Hello Ebsil, you can install the OpenG toolkit libraries with VIPM, there is a version for linux available as http://www.jki.net/vipm/download Regards, Ton On Fri, 25 Nov 2011 06:29:41 +0100, Ebsil Shyni <ebs...@gm...> wrote: > Sir, > > I need *OpenG (array, data and error) library* for database > connectivity to labview 7+ in Linux platform. > > Please provide the information as soon as possible... > > Thank you. > > -- -- Using Opera's revolutionary email client: http://www.opera.com/mail/ |
From: Ebsil S. <ebs...@gm...> - 2011-11-25 05:30:08
|
Sir, I need *OpenG (array, data and error) library* for database connectivity to labview 7+ in Linux platform. Please provide the information as soon as possible... Thank you. -- |
From: Jim K. <jk...@op...> - 2005-12-04 20:38:54
|
Hello All, I wanted to let you all know that OpenG has announced... Better Library Documentation, Examples, and Unit Testing: http://forums.openg.org/viewtopic.php?t=219 This change will be happening gradually, one package at a time. Thanks to Ashish Uttarwar for his help in adding these improvements to the dictionary package -- check out the dictionary example that shows how to manage a user database dictionary. Regards, -Jim Kring |
From: Jan K. <jan...@gm...> - 2005-09-07 15:34:48
|
Hello guys! Now I finally gave the new package builder a trial and have to say: Its great! Thanks a lot for making the creation of .spec files so much easier! But as as always, there is something to improve. I found it a cool feature to add the build package automatically to a specified OpenG package directory. Therefore I inserted some code to the existing package builder GUI and it works quite well. If you want to give it a chance just take a look. In the attachment I put all changed VIs, thus you just have to merge them into your own code base. (If you want I can send you a full .llb as well, but its big and I did not want to blow up your mail account.) To make this comfortable I had to enhance the spec-cluster and the stuff around it a bit as well, but there should not be any compatibility issues. Its just an additionally section "Deployment". I would be very happy to hear from you and even happier to see it merged into the main package. I'm looking forward to your suggestions Jan Klostermann PS: While digging through all the code I found a lot of useful stuff, not yet included in the OpenG-Toolkit. Did you think about doing so or is there anything against it? And second, did someone already thing about a diff-tool for packages, including a diff from a package to its installed files to figure out if anything was changed in the package VIs? |
From: Jim K. <jim...@ja...> - 2005-09-05 20:16:41
|
Hello Jan, Thanks for the bug report. I have opened a new bug entry in the tracker, here: http://sourceforge.net/tracker/index.php?func=detail&aid=1282507&group_id=52 435&atid=466832 The dynamic palette view and the package itself are quite complicated (due to complexities in the LabVIEW palettes) and I don't wish anyone to ever have to acquire the skill set necessary to maintain it. I'll work to get a new release out soon. Cheers, -Jim > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...] > On Behalf Of Jan Klostermann > Sent: Monday, September 05, 2005 3:19 AM > To: ope...@li... > Subject: [dynamicpalette] > > Hallo to all of you! > > I found a small bug in the dynamic palette distribution for > LabVIEW 7.1. > In the gmath.mnu is the mathpoly.mnu and the mathpolyrat.mnu missing. > The problem can be simply solved by copying all the three > mnu-files from > the LV7.1/menus/default dir to LV7.1/menus/dynamic. > > As I am not really familiar with the dynamicpalette package I > thought it > could be faster and easier if someone more into it could fix > it. But if > no one is gonna pick it up, I will take the time to do it... > > Thank for your support > > Jan > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development > Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * > Testing & QA > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > _______________________________________________ > OpenGToolkit-Developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers > > |
From: Jan K. <jan...@gm...> - 2005-09-05 10:18:59
|
Hallo to all of you! I found a small bug in the dynamic palette distribution for LabVIEW 7.1. In the gmath.mnu is the mathpoly.mnu and the mathpolyrat.mnu missing. The problem can be simply solved by copying all the three mnu-files from the LV7.1/menus/default dir to LV7.1/menus/dynamic. As I am not really familiar with the dynamicpalette package I thought it could be faster and easier if someone more into it could fix it. But if no one is gonna pick it up, I will take the time to do it... Thank for your support Jan |
From: Jim K. <jim...@ja...> - 2005-08-21 15:27:26
|
Hello All, I have posted OpenG NI Week presentation slides, photos, and audio here: http://forums.openg.org/viewtopic.php?t=153 It was great to see all of you who attended. -Jim Kring |
From: Jim K. <jim...@ja...> - 2005-07-27 16:08:00
|
Michael, An OpenG Package Builder "File Group" is analogous to an OpenG Builder "Destination". A Package spec file must have one or more File Groups. Each File Group inherits from global settings, but may override the global settings. File Group has Platform Requirements. If the requirements are not met, the File Group will not be installed. A File Group has a Source Directory, a Target Directory, and one or more Source Files. The Source Directory is specified relative to the package spec file location. All Source File paths are specified relative to the Source Directory, for example: <Source Directory path>/<Source File path>. When the package is installed on the target system the Source Files in the File Group will be installed at <Target Directory path>/<Source File path>. File Group N Platform Requirements Source Directory Target Directory Source File 1 ... ... Source File N One thing that is currently lacking, but just around the corner, is the ability to specify Source Files using wildcards and specify folders (recursively). Right now, each Source File must be specified separately. Regards, -Jim Kring > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...] > On Behalf Of Michael Aivaliotis > Sent: Wednesday, July 27, 2005 12:39 AM > To: ope...@li... > Subject: openg package builder help > > ok, I was trying the openg package builder but can't figure > out how to > use the "Package Files" tab. Can someone put together a quick startup > guide for this or just reply to this email with some hints? Nothing > makes any sense. It's not intuitive. What is file groups, > source, target > etc. Just to keep it simple: > > I have a bunch of VI's in a folder called c:\my_folder and I want to > have them installed under ...user.lib\michael. How would I > configure the > fields in this tab. > > I love this tool but some background knowledge seems to be > required. It > would be nice to be able to browse to a folder of VI's and > just specify > an installation target and then click go! then everything else is > automatic. Just an idea. > > Thank You > Michael Aivaliotis > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > OpenGToolkit-Developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers > |
From: Michael A. <mi...@ai...> - 2005-07-27 07:39:30
|
ok, I was trying the openg package builder but can't figure out how to use the "Package Files" tab. Can someone put together a quick startup guide for this or just reply to this email with some hints? Nothing makes any sense. It's not intuitive. What is file groups, source, target etc. Just to keep it simple: I have a bunch of VI's in a folder called c:\my_folder and I want to have them installed under ...user.lib\michael. How would I configure the fields in this tab. I love this tool but some background knowledge seems to be required. It would be nice to be able to browse to a folder of VI's and just specify an installation target and then click go! then everything else is automatic. Just an idea. Thank You Michael Aivaliotis |
From: Jean-Pierre D. <jea...@tr...> - 2005-07-20 08:03:26
|
Hello, I use the OpenG Builder on a rather large project (LV7.1, > 600 VIs , 2 executables) and I can tell you I won't go back to NIAB! Bravo guys! It works flawlessly as far as I know, the only minor point is that it does not remember the option to automatically reload the last file on startup. Some enhancements I'd like to see: An Open VI menu item. Since all VIs are usually closed before the build, we have to close the Builder to be able to access open menu again. Specify an installer file and optionally run it after the build. The most important feature: Static LLBs e.g. self-contained libraries that seldom change and do not need to be rebuild each time. These libraries would be simply copied (VIs are not saved individually) to their destination and other VIs are linked to them there. For my project I estimate that it would cut the build time by more than half. And what is this magic in OpenG Commander that makes some objects to adjust automagically to window resizing??? I might have some time for OpenG development in the near future, I'll take a closer look to see if I can make some of these improvements myself. Jean-Pierre |
From: Jim K. <jim...@ja...> - 2005-07-10 02:04:02
|
Hello All, It's taken a long time, and now you can finally Build Your Own Packages (.ogp files) using an intuitive user interface. The OpenG Package Builder UI is ready for public consumption, thanks to the hard work of Kostya Shifershteyn (who also brought us the OpenG Builder and MSI Installer Builder). You can download and install the ogrsc_package_builder package using OpenG Commander. There's more info here: http://www.openg.org/content/view/37/46/ Regards, -Jim Kring |
From: Michael A. <mi...@ai...> - 2005-07-01 04:50:36
|
That's fair. It doesn't hurt to post to both media outlets. What I meant to say was a "broader audience with various skill levels". It seems that the more resourceful developers can navigate the sourceforge pages and locate the mailing list. The Forums are a lot easier to get to. Come to think of it, perhaps the mailing list should be promoted more on the main OpenG website... -- Thank You Michael Aivaliotis Quoting Scott Hannahs <st...@ma...>: > On Jun 29, 2005, at 1:10 PM, Michael Aivaliotis wrote: > >> My opinion is to use the openg forums since you will get a larger audience. > Not to start a flame war, but that statement is based on what? > > Maybe a more focussed audience. The forums and the list server > *different* audiences. Try both out and see what fits your style. > > -Scott > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > OpenGToolkit-Developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers > |
From: Rolf K. <rol...@ci...> - 2005-06-30 10:11:00
|
> > 6. Password protected Vis > > 1. Tags can be written to and read from password protected files > > 2. Tag information is NOT encrypted Password protecting a VI does NOT encrypt the VI at all. This would make upgrading a password protected VI to a newer version impossible. Since the binary structure of a VI is LabVIEW private and only LabVIEW can interprete it in a meaningful way this is a pretty safe protection. LabVIEW itself can load the diagram independent of any applied password for recompilation when the VI is loaded into a different LabVIEW version or on a different LabVIEW platform. Rolf Kalbermatter |
From: Scott H. <st...@ma...> - 2005-06-29 21:25:50
|
On Jun 29, 2005, at 1:10 PM, Michael Aivaliotis wrote: > My opinion is to use the openg forums since you will get a larger > audience. Not to start a flame war, but that statement is based on what? Maybe a more focussed audience. The forums and the list server *different* audiences. Try both out and see what fits your style. -Scott |
From: Michael A. <mi...@ai...> - 2005-06-29 17:11:39
|
My opinion is to use the openg forums since you will get a larger audience. This means you will get more feedback. If you create a new topic then everyone can subscribe to it and be notified of new postings to the topic. -- Thank You Michael Aivaliotis Quoting Brian Gangloff <bri...@da...>: > I have been poking around the OpenG forums and noticed that perhaps some > of my announcements should go there. Should I move to the forums for > discussion or is the mailing list still the best? But as long as I have > your attention, I have another toolkit that I have ready for beta > "VI_Tag Toolkit" which is currently just wrapper VI's around the VI > tagging methods available from VI scripting. I had to password protect > the diagrams since scripting functions are not supposed to be available > to the public. I have been using the tagging methods for version > control since the tag data is available even if the front panel and/or > diagram is missing. I haven't applied it yet, but a tag could be > created for storing SCC version information as well. I have done some > testing and have found the following about the tag methods: > > Testing with VI Tag method > > 1. Set Tag will create and set a tag > 2. Set Tags will only change the data of an existing tag > 3. Blank LV 7.0 VI contains two tags > 1. NI.LV.ALL.VILastSavedTarget (string "Dflt") > 2. NI.LV.ALL.goodSyntaxTargets (1-D array of string [1], [ 0] > -> "Dflt") > 4. If remove above tags, they are rewritten when VI is saved > 5. Could not get Set Tags to change more than 1 tag > 1. Empty > 2. Regular expression > 3. Beginning > 6. Password protected Vis > 1. Tags can be written to and read from password protected files > 2. Tag information is NOT encrypted > > As you can see from item 5) I could not get the methods to change more > than one tag, although the name and output would indicate that it > should. My hope was that they would operate on the VI's callee's but > that is not the case. > > The installation is currently windows but I could post a zip file if > that is readable on the other platforms (I haven't had time to figure > out how to create a package). Here are the links: > http://www.dataact.com/VI_Tag.htm > http://www.dataact.com/downloads.htm > > Brian > |
From: Brian G. <bri...@da...> - 2005-06-29 14:46:55
|
I have been poking around the OpenG forums and noticed that perhaps some of my announcements should go there. Should I move to the forums for discussion or is the mailing list still the best? But as long as I have your attention, I have another toolkit that I have ready for beta "VI_Tag Toolkit" which is currently just wrapper VI's around the VI tagging methods available from VI scripting. I had to password protect the diagrams since scripting functions are not supposed to be available to the public. I have been using the tagging methods for version control since the tag data is available even if the front panel and/or diagram is missing. I haven't applied it yet, but a tag could be created for storing SCC version information as well. I have done some testing and have found the following about the tag methods: Testing with VI Tag method 1. Set Tag will create and set a tag 2. Set Tags will only change the data of an existing tag 3. Blank LV 7.0 VI contains two tags 1. NI.LV.ALL.VILastSavedTarget (string "Dflt") 2. NI.LV.ALL.goodSyntaxTargets (1-D array of string [1], [ 0] -> "Dflt") 4. If remove above tags, they are rewritten when VI is saved 5. Could not get Set Tags to change more than 1 tag 1. Empty 2. Regular expression 3. Beginning 6. Password protected Vis 1. Tags can be written to and read from password protected files 2. Tag information is NOT encrypted As you can see from item 5) I could not get the methods to change more than one tag, although the name and output would indicate that it should. My hope was that they would operate on the VI's callee's but that is not the case. The installation is currently windows but I could post a zip file if that is readable on the other platforms (I haven't had time to figure out how to create a package). Here are the links: http://www.dataact.com/VI_Tag.htm http://www.dataact.com/downloads.htm Brian |
From: <Dou...@mk...> - 2005-06-10 13:30:08
|
Jean-Pierre, using Variant to Data to convert a cluster to an array of variants does not work in LabVIEW 6.1; the array of variants that is returned is empty. I also tried converting an array of variants to a cluster (see below). One can use Variant to Data (in LabVIEW 7.1x) only if the original cluster can be converted to an array. First I tried wiring the array of variants to the "Variant" connector and the original cluster used to generate the array of variants to the "type" connector, but LabVIEW did not like that. If the original cluster can be converted to an array, though, converting the cluster to an array and then wiring that to the "Type" connector is something LabVIEW will accept, the resulting array being convertible back to a cluster. Code well and prosper! Doug (Embedded image moved to file: pic11777.pcx) |---------+---------------------------------------------------> | | Jean-Pierre Drolet | | | <jea...@tr...> | | | Sent by: | | | ope...@li...ur| | | ceforge.net | | | | | | | | | 06/09/2005 10:17 PM | | | Please respond to | | | opengtoolkit-developers | | | | |---------+---------------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: ope...@li... | | cc: | | Subject: Cluster to array of variants | >----------------------------------------------------------------------------------------------| Hi, I have just found in LV7.1 that you can convert a cluster to an array of variants simply using Variant to Data. That is probably much more efficient than the way it is actually done in lvdata, e.g. parsing thru flat data and TD. Can someone check if it is doable in LV6 (version used to develop lvdata)? I did not figure yet if there is an easier way to convert an array of variants to a cluster. Jean-Pierre ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 _______________________________________________ OpenGToolkit-Developers mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers This e-mail is intended solely for the person or entity to which it is addressed and may contain confidential information. Any review, dissemination, copying, printing or other use of this e-mail by persons or entities other than the addressee is prohibited. If you have received this e-mail in error, please contact the sender immediately and delete the material from any computer. |
From: Jean-Pierre D. <jea...@tr...> - 2005-06-10 02:17:30
|
Hi, I have just found in LV7.1 that you can convert a cluster to an array of variants simply using Variant to Data. That is probably much more efficient than the way it is actually done in lvdata, e.g. parsing thru flat data and TD. Can someone check if it is doable in LV6 (version used to develop lvdata)? I did not figure yet if there is an easier way to convert an array of variants to a cluster. Jean-Pierre |
From: Brian G. <bri...@da...> - 2005-05-23 19:39:06
|
There is an updated installer available for dqGOOP on our website. Here is a list of the changes: * Added methods for reading locked data * Installer will allow installing into all LabVIEW versions greater or equal to 7.0 * Installer allows mass compiling if required (Warning EXIT LabVIEW before selecting YES) * Wizard will move the custom probes to the ..\user.lib\-probes\default directory * Help file updated with new VIs and performance charts Please uninstall the previous version before installing this one. Follow the link on the downloads page for the new installer http://www.dataact.com/downloads.htm The help file is available on line here http://www.dataact.com/dqGOOP.htm Let me know if anyone has any questions Brian |
From: Jan K. <klo...@rh...> - 2005-05-23 16:40:37
|
Hi Jim & Jean-Pierre, I think it is useful to enhance the VIs like you mentioned. But before you start it would be really nice, if you could merge my changes that I sent to Jim some months ago. Otherwise I get in even more trouble to keep things together and the chance of still quite easy merging is gone. Therefore thank in advance for getting my changes in before you put yours into it. Jan -----Urspr=FCngliche Nachricht----- Von: ope...@li... [mailto:ope...@li...] Im Auftrag von ope...@li... Gesendet: Samstag, 21. Mai 2005 05:10 An: ope...@li... Betreff: OpenGToolkit-Developers digest, Vol 1 #146 - 1 msg Send OpenGToolkit-Developers mailing list submissions to ope...@li... To subscribe or unsubscribe via the World Wide Web, visit =09 https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers or, via email, send a message with subject or body 'help' to ope...@li... You can reach the person managing the list at ope...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenGToolkit-Developers digest..." Today's Topics: 1. RE: GOOP and INI files (Jim Kring) --__--__-- Message: 1 From: "Jim Kring" <jim...@ja...> To: <ope...@li...> Subject: RE: GOOP and INI files Date: Fri, 20 May 2005 08:56:05 -0700 Reply-To: ope...@li... Jean-Pierre, I was also thinking that it would be very useful for all classes to provide generic forms of the Get/Set Data methods. These would have a variant data input/output and also take a U32 reference input/output. This would enable the creation of many kinds of useful utilities to operate on OpenGOOP classes. For example, I am interested in an data inspector/editor. The utility that you mentioned would also be very useful. -Jim > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...]=20 > On Behalf Of Jean-Pierre Drolet > Sent: Thursday, May 19, 2005 8:04 AM > To: ope...@li... > Subject: GOOP and INI files >=20 > I'm currently facing the problem of writing/reading objects > to/from INI=20 > files. > In the file each object data is stored in a separate section named=20 > [Classname::ObjectID] (the classname is to easily identify=20 > all objects=20 > of a given class in a file). >=20 > An object refnum key holds the ObjectID > ObjectRef=3DObjectID >=20 > I'd like to modify OGTK Read Key (Variant) and Write Key (Variant) so > that it identifes GOOP refnums (refnum to a file of enum=20 > data), get the=20 > variant object data and write it as a section (write) or get=20 > the variant=20 > data type and read the appropriate section (read) >=20 > This would be straightforward using inheritance but how to access an > object variant data in a generic way without inheritance? > The information available in a GOOP refnum (as a variant) is the=20 > classname (enum item 0) and the name of the typedef control.=20 > Opening a=20 > reference to the typedef control, we can read its path (then=20 > locate the=20 > VIs of the class). One can locate the GetData method of the=20 > object but=20 > it can't be dynamically called (unknown conn pane) or run (it=20 > is usually=20 > reserved for call). Should each class have generic Get/Set Data as=20 > Variant VI with fixed connector pane? >=20 > Any other idea? Please discuss >=20 > Jean-Pierre >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be=20 > the first software developer in space? Enter now for the Oracle Space=20 > Sweepstakes! = http://ads.osdn.com/?ad_id=3D7412&alloc_id=3D16344&op=3Dclick > _______________________________________________ > OpenGToolkit-Developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers >=20 --__--__-- _______________________________________________ OpenGToolkit-Developers mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers End of OpenGToolkit-Developers Digest |
From: Jim K. <jim...@ja...> - 2005-05-20 15:56:22
|
Jean-Pierre, I was also thinking that it would be very useful for all classes to provide generic forms of the Get/Set Data methods. These would have a variant data input/output and also take a U32 reference input/output. This would enable the creation of many kinds of useful utilities to operate on OpenGOOP classes. For example, I am interested in an data inspector/editor. The utility that you mentioned would also be very useful. -Jim > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...] > On Behalf Of Jean-Pierre Drolet > Sent: Thursday, May 19, 2005 8:04 AM > To: ope...@li... > Subject: GOOP and INI files > > I'm currently facing the problem of writing/reading objects > to/from INI > files. > In the file each object data is stored in a separate section named > [Classname::ObjectID] (the classname is to easily identify > all objects > of a given class in a file). > > An object refnum key holds the ObjectID > ObjectRef=ObjectID > > I'd like to modify OGTK Read Key (Variant) and Write Key (Variant) so > that it identifes GOOP refnums (refnum to a file of enum > data), get the > variant object data and write it as a section (write) or get > the variant > data type and read the appropriate section (read) > > This would be straightforward using inheritance but how to access an > object variant data in a generic way without inheritance? > The information available in a GOOP refnum (as a variant) is the > classname (enum item 0) and the name of the typedef control. > Opening a > reference to the typedef control, we can read its path (then > locate the > VIs of the class). One can locate the GetData method of the > object but > it can't be dynamically called (unknown conn pane) or run (it > is usually > reserved for call). Should each class have generic Get/Set Data as > Variant VI with fixed connector pane? > > Any other idea? Please discuss > > Jean-Pierre > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click > _______________________________________________ > OpenGToolkit-Developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers > |
From: Jean-Pierre D. <jea...@tr...> - 2005-05-19 15:00:48
|
I'm currently facing the problem of writing/reading objects to/from INI files. In the file each object data is stored in a separate section named [Classname::ObjectID] (the classname is to easily identify all objects of a given class in a file). An object refnum key holds the ObjectID ObjectRef=ObjectID I'd like to modify OGTK Read Key (Variant) and Write Key (Variant) so that it identifes GOOP refnums (refnum to a file of enum data), get the variant object data and write it as a section (write) or get the variant data type and read the appropriate section (read) This would be straightforward using inheritance but how to access an object variant data in a generic way without inheritance? The information available in a GOOP refnum (as a variant) is the classname (enum item 0) and the name of the typedef control. Opening a reference to the typedef control, we can read its path (then locate the VIs of the class). One can locate the GetData method of the object but it can't be dynamically called (unknown conn pane) or run (it is usually reserved for call). Should each class have generic Get/Set Data as Variant VI with fixed connector pane? Any other idea? Please discuss Jean-Pierre |
From: Brian G. <bri...@da...> - 2005-05-17 20:40:52
|
Here is the performance summary including dqGOOP with the ability of reading locked data: GOOP Performance Comparison Graph The updated test classes are located here: http://downloads.dataact.com/dqGOOP/GOOPTestClasses.zip If you just want to see the changes to dqGOOP this is a smaller file to download: http://downloads.dataact.com/dqGOOP/dqClass(Locked).zip I have not updated the documentation or the installer yet. Brian |
From: Brian G. <bri...@da...> - 2005-05-11 00:41:41
|
Brian Gangloff wrote: > As I was writing this I got an idea, use a temporary queue to store > the last data (see > http://downloads.dataact.com/dqGOOP/dqClass(Last).zip). The benefit > of this approach is that the new functions behave and perform about > the same as the originals. However, this comes at the expense of > enabling the last data. I threw this together quickly so there may be > some errors, but at least everyone can get a preview of another > possible solution. Here's a better performing concept. This time use uninitialized shift reg to store the last data when needed. The new getDataToModifyStoreLast could be sped even more up by eliminating the preview to get the data before it is removed from the queue. It would then be possible (very slight) that the getData function could call after the data is removed from the queue, but before the data is put in the shift reg. http://downloads.dataact.com/dqGOOP/dqClass(Last2).zip |
From: Christopher R. <chr...@ya...> - 2005-05-10 03:50:37
|
Looks impressive! --- EULA 1) This is a private email, and although the views expressed within it = may not be purely my own, unless specifically referenced I do not suggest = they are necessarily associated with anyone else including, but not limited = to, my employer(s). 2) This email has NOT been scanned for virii - attached file(s), if any, = are provided as is. By copying, detaching and/or opening attached files, you agree to indemnify the sender of such responsibility. 3) Because e-mail can be altered electronically, the integrity of this communication cannot be guaranteed. -----Original Message----- From: ope...@li... [mailto:ope...@li...] On Behalf = Of Brian Gangloff Sent: Tuesday, May 10, 2005 1:13 PM To: ope...@li... Subject: Re: dqGOOP beta Dou...@mk... wrote: >What performance benchmarks comparing OpenGOOP and dqGOOP can you share = >with us? Doug > =20 > The attached spreadsheet has data from running the test classes that are = in the zip file. I plan on running the test under more controlled=20 conditions, but the results are typical of what I have been seeing. = Brian |