From: Peter J. F. I. <pjf...@ea...> - 2013-02-13 06:30:52
|
I have reviewed the reference manual documentation on the OPEN method, and I do not see any option to specify the encoding of the input stream. Is it possible to specify the input stream encoding anywhere? In particular, I have some UTF-8 text produced by Xpdf's pdftotext utility that I want to read and be able to specify UTF-8 character constants in my Rexx program code (also encoded in UTF-8) to be compared against the UTF-8 input characters. For instance, a superscript "1" in UTF-8 is actually encoded as two 8-bit characters, hex representation 'C2B9'X. In my UTF-8 Rexx code, I would code a string constant to check for that superscript "1" as a quote, a superscript "1" and another quote, which displays as if it is three characters in the UTF-8 editor I use. If I am barking up the wrong tree here, please just guide me in the right direction. TIA for any help or RTFM you can provide. Regards, Peter |
From: Jean-Louis F. <jfa...@gm...> - 2013-02-13 07:39:20
|
ooRexx does not manage encodings, but that doesn't forbid to use UTF-8 (at least under Windows and Unix, can't tell for other platforms). You can open your UTF-8 files as text files, read them, rewrite them, there is no loss of bytes. The BIF and String class work at the byte level : "my UTF-8 string"~length returns the number of bytes, not the number of characters. "my UTF-8 string"~pos(superscript1) returns the position in byte-count. etc... It's ok to have a source file encoded in UTF-8, but only the string constants can contain UTF-8 characters, according the rules described in section "1.10.4. Tokens" in rexxref.pdf 2013/2/13 Peter J. Farley III <pjf...@ea...> > I have reviewed the reference manual documentation on the OPEN method, and > I do not see any option to specify the encoding of the input stream.**** > > ** ** > > Is it possible to specify the input stream encoding anywhere? In > particular, I have some UTF-8 text produced by Xpdf’s pdftotext utility > that I want to read and be able to specify UTF-8 character constants in my > Rexx program code (also encoded in UTF-8) to be compared against the UTF-8 > input characters.**** > > ** ** > > For instance, a superscript “1” in UTF-8 is actually encoded as two 8-bit > characters, hex representation ‘C2B9’X. In my UTF-8 Rexx code, I would > code a string constant to check for that superscript “1” as a quote, a > superscript “1” and another quote, which displays as if it is three > characters in the UTF-8 editor I use.**** > > ** ** > > If I am barking up the wrong tree here, please just guide me in the right > direction.**** > > ** ** > > TIA for any help or RTFM you can provide.**** > > ** ** > > Regards,**** > > ** ** > > Peter**** > > ** ** > > > ------------------------------------------------------------------------------ > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > _______________________________________________ > Oorexx-users mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-users > > |
From: Peter J. F. I. <pjf...@ea...> - 2013-02-13 15:02:17
|
Thanks Jean-Louis, that answers all my questions Peter From: Jean-Louis Faucher [mailto:jfa...@gm...] Sent: Wednesday, February 13, 2013 2:39 AM To: Open Object Rexx Users Subject: Re: [Oorexx-users] Can UTF-8 input streams be read as UTF-8? ooRexx does not manage encodings, but that doesn't forbid to use UTF-8 (at least under Windows and Unix, can't tell for other platforms). You can open your UTF-8 files as text files, read them, rewrite them, there is no loss of bytes. The BIF and String class work at the byte level : "my UTF-8 string"~length returns the number of bytes, not the number of characters. "my UTF-8 string"~pos(superscript1) returns the position in byte-count. etc... It's ok to have a source file encoded in UTF-8, but only the string constants can contain UTF-8 characters, according the rules described in section "1.10.4. Tokens" in rexxref.pdf 2013/2/13 Peter J. Farley III <pjf...@ea...> I have reviewed the reference manual documentation on the OPEN method, and I do not see any option to specify the encoding of the input stream. Is it possible to specify the input stream encoding anywhere? In particular, I have some UTF-8 text produced by Xpdfs pdftotext utility that I want to read and be able to specify UTF-8 character constants in my Rexx program code (also encoded in UTF-8) to be compared against the UTF-8 input characters. For instance, a superscript 1 in UTF-8 is actually encoded as two 8-bit characters, hex representation C2B9X. In my UTF-8 Rexx code, I would code a string constant to check for that superscript 1 as a quote, a superscript 1 and another quote, which displays as if it is three characters in the UTF-8 editor I use. If I am barking up the wrong tree here, please just guide me in the right direction. TIA for any help or RTFM you can provide. Regards, Peter -- |
From: Art H. <art...@ar...> - 2013-02-14 16:07:27
|
I am using NSIS for the install script for my Rexx program and associated files. I have tried with it to get the icon that I supply to show with the icon that is setup on the desktop and in the Start Menu folder, but have not been successful. Is there a way in my ooRexx program that I can change the default Icon that is displayed in the .lnk file - if so, I could use that to change it on the initial execution of the ooRexx program. I have the icon properly being displayed on the main dialog panel and that is all okay - I just am wanting to get the ooRexx icon changed on the start icon for the program. I have been in contact with the NSIS developers, but have not gotten an answer yet - I suspect the problem is due to specifying the .rex file as the executable - that it is not an .exe or .dll file. If I look at the properties of the startup .lnk file, the .ico file is included as a parameter to the ooRexx program as: C:\folder\program.rex C:\folder\program.ico but Windows does not pick that up as an icon for the startup icon. -- Art Heimsoth - art...@ar... |
From: Mark M. <mie...@gm...> - 2013-02-14 16:43:13
|
On Thu, Feb 14, 2013 at 8:07 AM, Art Heimsoth <art...@ar...>wrote: > I am using NSIS for the install script for my Rexx program and associated > files. I have tried with it to get the icon that I supply to show with the > icon that is setup on the desktop and in the Start Menu folder, but have > not been successful. Is there a way in my ooRexx program that I can change > the default Icon that is displayed in the .lnk file - if so, I could use > that to > change it on the initial execution of the ooRexx program. Hi Art, You are not going to have much luck with that, I don't think. The Windows shell is always going to want an executable or DLL with the icon bound into it, and the index of that icon, I believe. Your best bet would be to compile a resource only DLL and bind the icon to that. Then use that DLL as the icon file name with the index you use for the icon resource. Compiling a resource only DLL is really pretty simple. If you have a working NSIS install script, you can easily compile a resource only DLL. It just involves downloading and installing a Windows SDK. The SDK is free. Oliver Sims who is writing the ooDialog User Guide, has mastered that. I'm sure he would answer any questions concerning the details. You could look at the winsystm.cls, where the WindowsProgramManager class has the addDesktopIcon method. It might help, but I think not. I think the Windows Shell requires the icon to be in a compiled resource. It is not going to load an icon from an icon file. -- Mark Miesfeld |
From: Art H. <art...@ar...> - 2013-02-14 16:51:05
|
> On Thu, Feb 14, 2013 at 8:07 AM, Art Heimsoth > <art...@ar...> wrote: > >> I am using NSIS for the install script for my Rexx program and >> associated >> > files. I have tried with it to get the icon that I supply to show > with the icon that is setup on the desktop and in the Start Menu > folder, but have not been successful. Is there a way in my ooRexx > program that I can change the default Icon that is displayed in the > .lnk file - if so, I could use that to change it on the initial > execution of the ooRexx program. > > > Hi Art, > > > You are not going to have much luck with that, I don't think. The > Windows shell is always going to want an executable or DLL with the > icon bound into it, and the index of that icon, I believe. > > > Your best bet would be to compile a resource only DLL and bind the > icon to that. Then use that DLL as the icon file name with the > index you use for the icon resource. > > > Compiling a resource only DLL is really pretty simple. If you have > a working NSIS install script, you can easily compile a resource > only DLL. It just involves downloading and installing a Windows > SDK. The SDK is free. > > > Oliver Sims who is writing the ooDialog User Guide, has mastered > that. I'm sure he would answer any questions concerning the > details. > > > You could look at the winsystm.cls, where the WindowsProgramManager > class has the addDesktopIcon method. It might help, but I think > not. I think the Windows Shell requires the icon to be in a > compiled resource. It is not going to load an icon from an icon > file. > > > -- > Mark Miesfeld Thanks Mark, that at least gives me a direction to go. -- Art Heimsoth - art...@ar... |
From: Art H. <art...@ar...> - 2013-02-14 19:03:19
|
> On Thu, Feb 14, 2013 at 8:07 AM, Art Heimsoth > <art...@ar...> wrote: > > > Your best bet would be to compile a resource only DLL and bind the > icon to that. Then use that DLL as the icon file name with the > index you use for the icon resource. > > > Compiling a resource only DLL is really pretty simple. If you have > a working NSIS install script, you can easily compile a resource > only DLL. It just involves downloading and installing a Windows > SDK. The SDK is free. > > > Oliver Sims who is writing the ooDialog User Guide, has mastered > that. I'm sure he would answer any questions concerning the > details. > > -- > Mark Miesfeld Are there advantages to incorporate all the resources currently defined in the .rc file and build it all into a dll and switch to use the ResDialog with this icon resource also included? Would I still need the .h file to continue to use symbolic IDs? I suppose it is too much to ask if there is a simple example available on how to put this all together? -- Art Heimsoth - art...@ar... |
From: Mark M. <mie...@gm...> - 2013-02-14 20:03:23
|
On Thu, Feb 14, 2013 at 11:03 AM, Art Heimsoth <art...@ar...>wrote: > > On Thu, Feb 14, 2013 at 8:07 AM, Art Heimsoth > > <art...@ar...> wrote: > > > > > Your best bet would be to compile a resource only DLL and bind the > > icon to that. Then use that DLL as the icon file name with the > > index you use for the icon resource. > > Are there advantages to incorporate all the resources currently defined > in the .rc file and build it all into a dll and switch to use the ResDialog > with this icon resource also included? Yes, I think there are definite advantages, especially if you are distributing an "application" that is more than the simple examples we send with ooDialog. * Even if you are using .rc files instead of a UserDialog, ooDialog still has to parse the .rc file and construct an in-memory dialog template. If you have other resources like bitmaps and icons, the image files have to be loaded from disk and converted into in-memory structures. Once that is done, then ooDialog can start the underlying dialog. With a DLL all of that is done ahead of time. The operating system can load a DLL very fast, and then ooDialog can start the dialog. You wouldn't be able to see any difference to the eye, unless you had a really hugh ooDialog application, but using a ResDialog is much faster than using a RcDialog. * If you have a number of bitmaps, menus, icons, *.rc files, once you compile it into a DLL you only have 1 file to manage. I myself would always use a ResDialog. But, for showing examples to other people, it is easy for the "other" people if they have text files they can look at. I guess really the biggest advantage is scaling. Using text .rc files and including *.bmp, *.ico files is fine and simple for small example programs. But that technique does not scale well. > Would I still need the .h file to > continue to use symbolic IDs? You do. The .h file is needed to feed to the compiler. And it is then also needed for your Rexx code to translate the symbols to numbers. The .h file needs to be 'inlcuded' in the .rc file, or the rc compiler won't be able to compile the .rc script. Look at some of the .rc files included with the examples, you will see something similar to: #include "ApplicationIcon.h" in them. The actual *.h file is the one that has the symbol defines that both the rc compiler and your Rexx program needs and uses. > I suppose it is too much to ask if there > is a simple example available on how to put this all together? > In the extra examples package that you can download from SourceForge from the ooDialog section, there is a makeDLL.rex program and a read me for it that can help. With the makeDLL.rex program, you can recompile the resource only DLLs that are used for some of the example programs in the extra examples package. The read me walks you through the process. I believed at the time I wrote the read me that it would be a sufficiently simple example to show people how to put this all together. However, since I've had a lot of disparaging comments on my documentation skills, I'm not sure if it is sufficient. It should be close to sufficient. ;-) I'll give you help if you get stuck anywhere. Also, I know that Oliver did not know how to compile a resource only DLL when he started writing the user guide, and he does now. I'm sure he can help also. -- Mark Miesfeld |
From: Mark M. <mie...@gm...> - 2013-02-14 20:06:16
|
On Thu, Feb 14, 2013 at 12:03 PM, Mark Miesfeld <mie...@gm...> wrote: > > In the extra examples package that you can download from SourceForge from > the ooDialog section, there is a makeDLL.rex program and a read me for it > that can help. > https://sourceforge.net/projects/oorexx/files/ooDialog/Additional.Samples/ When you install the package, look in the top-level directory for makeDLL.* -- Mark Miesfeld |
From: Mark M. <mie...@gm...> - 2013-02-15 00:55:24
|
On Thu, Feb 14, 2013 at 12:06 PM, Mark Miesfeld <mie...@gm...> wrote: > On Thu, Feb 14, 2013 at 12:03 PM, Mark Miesfeld <mie...@gm...>wrote: > >> >> In the extra examples package that you can download from SourceForge from >> the ooDialog section, there is a makeDLL.rex program and a read me for it >> that can help. >> > > > https://sourceforge.net/projects/oorexx/files/ooDialog/Additional.Samples/ > > > Art, I have updated the extra samples package to 0.0.7. In that I added a simple example, reviewed the makeDLL.ReadMe file and added a read me file to the simple example. I believe that if you look through that, you will not have any trouble compiling your own resource-only DLL. It is a lot easier than creating a working NSIS install script. One thing, since you have been writing your own .rc file, you will need icon and bitmap statements in it for those resources. You may already know that. If not take a look at: makeDLL.example\AnimalGame.rc in the 0.0.7 package for some help. -- Mark Miesfeld |
From: Mukenx <mu...@gm...> - 2013-02-15 19:30:41
|
Resedit also allows to easily compile a resource dll from icons and rc files. It also allows the extraction of icons embedded in exe or dll files. I think there is a section in the oodialog user guide about it. Worth exploring... Madou Am 15.02.2013 01:55 schrieb "Mark Miesfeld" <mie...@gm...>: > > > On Thu, Feb 14, 2013 at 12:06 PM, Mark Miesfeld <mie...@gm...>wrote: > >> On Thu, Feb 14, 2013 at 12:03 PM, Mark Miesfeld <mie...@gm...>wrote: >> >>> >>> In the extra examples package that you can download from SourceForge >>> from the ooDialog section, there is a makeDLL.rex program and a read me for >>> it that can help. >>> >> >> >> https://sourceforge.net/projects/oorexx/files/ooDialog/Additional.Samples/ >> >> >> > Art, > > I have updated the extra samples package to 0.0.7. In that I added a > simple example, reviewed the makeDLL.ReadMe file and added a read me file > to the simple example. > > I believe that if you look through that, you will not have any trouble > compiling your own resource-only DLL. It is a lot easier than creating a > working NSIS install script. > > One thing, since you have been writing your own .rc file, you will need > icon and bitmap statements in it for those resources. You may already know > that. If not take a look at: > > makeDLL.example\AnimalGame.rc > > in the 0.0.7 package for some help. > > -- > Mark Miesfeld > > > ------------------------------------------------------------------------------ > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > _______________________________________________ > Oorexx-users mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-users > > |
From: Art H. <art...@ar...> - 2013-02-16 01:41:42
|
Thanks for all the help and suggestions, but I have run into a road block for right now. I downloaded and installed the SDK 7.1 level on my XP system - the SDK for Windows 8 does not support XP. When I execute the SetEnv.cmd file, it does not find any C compiler nor the link executable. I then tried to get my .rc file to work with ResEdit, but there is a problem with the DateTimePicker in that I can define the attribute of ShortDateCenturyFormat with it, but then it will not reload the .rc file - it flags that identifier as being undeclared. I am about to try to install the Visual C++ 2010 Express version - the 2012 version also does not support XP. Is there a better solution that you are aware of? Thanks, Art > Resedit also allows to easily compile a resource dll from icons > and rc files. It also allows the extraction of icons embedded in > exe or dll files. > I think there is a section in the oodialog user guide about it. > Worth exploring... Madou > Am 15.02.2013 01:55 schrieb "Mark Miesfeld" <mie...@gm...>: > > >> On Thu, Feb 14, 2013 at 12:06 PM, Mark Miesfeld >> <mie...@gm...> wrote: >> >>> On Thu, Feb 14, 2013 at 12:03 PM, Mark Miesfeld >>> <mie...@gm...> wrote: >> >> >>>> In the extra examples package that you can download from >>>> SourceForge from the ooDialog section, there is a makeDLL.rex >>>> program and a read me for it that can help. >>> >>> >>> https://sourceforge.net/projects/oorexx/files/ooDialog/Additional.Samp >>> les/ >>> >> >> Art, >> >> >> I have updated the extra samples package to 0.0.7. In that I >> added a simple example, reviewed the makeDLL.ReadMe file and >> added a read me file to the simple example. >> > >> I believe that if you look through that, you will not have any >> trouble compiling your own resource-only DLL. It is a lot easier >> than creating a working NSIS install script. >> >> >> One thing, since you have been writing your own .rc file, you >> will need icon and bitmap statements in it for those resources. >> You may already know that. If not take a look at: >> > >> makeDLL.example\AnimalGame.rc >> >> >> in the 0.0.7 package for some help. >> >> >> -- >> Mark Miesfeld >> > |
From: Mark M. <mie...@gm...> - 2013-02-16 02:05:39
|
On Fri, Feb 15, 2013 at 5:41 PM, Art Heimsoth <art...@ar...>wrote: > Thanks for all the help and suggestions, but I have run into a road block > for right now. I downloaded and installed the SDK 7.1 level on my XP > This is still the best bet, or maybe VC++ 2010. I should have told you not to try Windows 8 SDK or VC++ 2012. > system - the SDK for Windows 8 does not support XP. When I execute > the SetEnv.cmd file, it does not find any C compiler nor the link > executable. > I then tried to get my .rc file to work with ResEdit, but there is a > problem > with the DateTimePicker in that I can define the attribute of > ShortDateCenturyFormat > with it, but then it will not reload the .rc file - it flags that > identifier as > being undeclared. I am about to try to install the Visual C++ 2010 Express > version > Well, I just looked and VC++ 2010 is probably what you need. The Windows SDKs used to include a linker, but 7.1 does not anymore. VC++ 2010 should work fine. The Resedit problem can be fixed by making sure the right includes are done. I'll have to look up what is needed. -- Mark Miesfeld |
From: Mark M. <mie...@gm...> - 2013-02-16 02:16:54
|
On Fri, Feb 15, 2013 at 6:05 PM, Mark Miesfeld <mie...@gm...> wrote: > On Fri, Feb 15, 2013 at 5:41 PM, Art Heimsoth <art...@ar...>wrote: > >> Thanks for all the help and suggestions, but I have run into a road block >> for right now. I downloaded and installed the SDK 7.1 level on my XP >> > > > > The Resedit problem can be fixed by making sure the right includes are > done. I'll have to look up what is needed. > > In your resource file do you have these includes at the top? #include <windows.h> #include <winuser.h> #include <commctrl.h> #include "whatever your .h file is" When I have DTS_SHORTDATECENTURYFORMAT in my .rc file, resedit loads it okay. But in the properties for the date time picker, resedit always shows long format. Still, if I change it to short date century and save, it does write out DTS_SHORTDATECENTURYFORMAT to the .rc file This worked for me: resedit -convert userStringDTP.rc userStringDTP.dll userStringDTP.rc has the .flag in it. I'd try VC++ 2010, it should work. -- Mark Miesfeld |
From: Art H. <art...@ar...> - 2013-02-16 03:26:26
|
> On Fri, Feb 15, 2013 at 6:05 PM, Mark Miesfeld <mie...@gm...> > wrote: > >> On Fri, Feb 15, 2013 at 5:41 PM, Art Heimsoth >> <art...@ar...> wrote: >> >> >>> Thanks for all the help and suggestions, but I have run into a >>> road block >>> > for right now. I downloaded and installed the SDK 7.1 level on my > XP >> >> > The Resedit problem can be fixed by making sure the right includes > are done. I'll have to look up what is needed. >> > > In your resource file do you have these includes at the top? > > > #include <windows.h> > #include <winuser.h> > #include <commctrl.h> I had #include <richedit.h> and not the #include <winuser.h> but when I added the winuser.h it did not make any difference. I still get the undefined error. In looking at the includes, the #define for that attribute is defined in Commctrl.h and has a #if around it of #if (_WIN32_IE >= 0x500) so that tells me that my Win32_IE is not >= 0x500 - do you know how/where that value is specified or what it represents? I am runing 32 bit XP with IE 8.0. > > #include "whatever your .h file is" > > > When I have DTS_SHORTDATECENTURYFORMAT in my .rc file, resedit > loads it okay. But in the properties for the date time picker, > resedit always shows long format. Still, if I change it to short > date century and save, it does write out DTS_SHORTDATECENTURYFORMAT > to the .rc file > > > This worked for me: > > > resedit -convert userStringDTP.rc userStringDTP.dll > > > userStringDTP.rc has the .flag in it. > > > I'd try VC++ 2010, it should work. Yes, it works just fine.. but until I find out why the WIN32_IE is not satisfying the #if statement, I will continue to maintain the .rc manually. > -- > Mark Miesfeld -- Art Heimsoth - art...@ar... |
From: Mark M. <mie...@gm...> - 2013-02-16 04:48:47
|
On Fri, Feb 15, 2013 at 7:26 PM, Art Heimsoth <art...@ar...>wrote: > > > #include <windows.h> > > #include <winuser.h> > > #include <commctrl.h> > > I had #include <richedit.h> and not the #include <winuser.h> but > when I added the winuser.h it did not make any difference. I still > get the undefined error. In looking at the includes, the #define for > that attribute is defined in Commctrl.h and has a #if around it of > #if (_WIN32_IE >= 0x500) > so that tells me that my Win32_IE is not >= 0x500 - do you know > how/where that value is specified or what it represents? I am runing > 32 bit XP with IE 8.0. > You can define it yourself. Just add this: #define _WIN32_IE 0x0600 ahead of the includes #include <windows.h> #include <winuser.h> #include <commctrl.h> > > I'd try VC++ 2010, it should work. > > Yes, it works just fine.. but until I find out why the WIN32_IE is > not satisfying the #if statement, I will continue to maintain the > .rc manually. > The defines are meant for you to add. This is what I have for the ooDialog source code: #define NTDDI_VERSION NTDDI_LONGHORN #define _WIN32_WINNT 0x0600 #define _WIN32_IE _WIN32_IE_IE70 #define WINVER 0x0600 -- Mark Miesfeld |
From: Staffan T. <sta...@gm...> - 2013-02-16 15:26:47
|
Thanks to this thread many questions that I've had in mind have been answered. :) Staffan On Sat, Feb 16, 2013 at 5:48 AM, Mark Miesfeld <mie...@gm...> wrote: > On Fri, Feb 15, 2013 at 7:26 PM, Art Heimsoth <art...@ar...>wrote: > >> >> > #include <windows.h> >> > #include <winuser.h> >> > #include <commctrl.h> >> >> I had #include <richedit.h> and not the #include <winuser.h> but >> when I added the winuser.h it did not make any difference. I still >> get the undefined error. In looking at the includes, the #define for >> that attribute is defined in Commctrl.h and has a #if around it of >> #if (_WIN32_IE >= 0x500) >> so that tells me that my Win32_IE is not >= 0x500 - do you know >> how/where that value is specified or what it represents? I am runing >> 32 bit XP with IE 8.0. >> > > You can define it yourself. Just add this: > > #define _WIN32_IE 0x0600 > > ahead of the includes > > #include <windows.h> > #include <winuser.h> > #include <commctrl.h> > > >> > I'd try VC++ 2010, it should work. >> >> Yes, it works just fine.. but until I find out why the WIN32_IE is >> not satisfying the #if statement, I will continue to maintain the >> .rc manually. >> > > The defines are meant for you to add. This is what I have for the > ooDialog source code: > > #define NTDDI_VERSION NTDDI_LONGHORN > #define _WIN32_WINNT 0x0600 > #define _WIN32_IE _WIN32_IE_IE70 > #define WINVER 0x0600 > > -- > Mark Miesfeld > > > ------------------------------------------------------------------------------ > The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, > is your hub for all things parallel software development, from weekly > thought > leadership blogs to news, videos, case studies, tutorials, tech docs, > whitepapers, evaluation guides, and opinion stories. Check out the most > recent posts - join the conversation now. > http://goparallel.sourceforge.net/ > _______________________________________________ > Oorexx-users mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-users > > |
From: Art H. <art...@ar...> - 2013-02-17 17:42:18
|
I am now running into difficulty with the menus. I am using the ScriptMenuBar sample from samples/dialog/menus as a sample guide. I changed the dlg = .SimpleDialog~new ... to use the .dll file instead of the .rc file. I changed the ::class statement to use ResDialog instead of RcDialog and then changed the menubar = .ScriptMenuBar to be .BinaryMenuBar to the following: menuBar = .BinaryMenuBar~new("ScriptMenuBar.dll", IDR_MENU_LV, , self, .true, self) but now the menu bar does not appear to be working in that the methods like addItemsFromFile or openList-View do not get control. This is similar to what is happening in my rex script with the menus, so there must be something more I need to get the menu bar linked to the methods but I don't know what or where this something needs to go. -- Art Heimsoth - art...@ar... |
From: Staffan T. <sta...@gm...> - 2013-02-17 17:48:49
|
Maybe a missing assignTo? Staffan |
From: Art H. <art...@ar...> - 2013-02-17 18:51:41
|
> Maybe a missing assignTo? > > Staffan Mark's reply with the change needed to the .BinaryMenuBar is what was needed. In reading further in 24.2.1 I now see where there are multiple ways of connecting events to the menu bar, and not all ways work the same for RcDialog as for ResDialog. I am off again to find the next difference, as not all of my dialogs are working correctly yet. Thanks all for your pointers and help. -- Art Heimsoth - art...@ar... |
From: hakan <he...@us...> - 2013-02-17 19:31:29
|
Art I use these for menues ( I always start with ..rc files, when all is OK I copy to a second source (.rexx )) Script: menubar = .scriptmenubar~new(self~dialogName".rc",IDR_MENU1) menubar~attachto(self) Binary (.dll) menubar = .binarymenubar~new(self~dialogName".dll",IDR_MENU1) menubar~attachto(self) then it's just to replace scriptmenubar with binarymenubar and .rc with .dll in new .rexx and then rexxc .rexx to .rex /hex ------------------------- Ursprungligt Meddelande: Från: Art Heimsoth <art...@ar...> Till: Open Object Rexx Users <oor...@li...> Kopia: Datum: söndag, 17 februari 2013 19:51 Ämne: Re: [Oorexx-users] Changing from RcDialog to ResDialog > Maybe a missing assignTo? > > Staffan Mark's reply with the change needed to the .BinaryMenuBar is what was needed. In reading further in 24.2.1 I now see where there are multiple ways of connecting events to the menu bar, and not all ways work the same for RcDialog as for ResDialog. I am off again to find the next difference, as not all of my dialogs are working correctly yet. Thanks all for your pointers and help. -- Art Heimsoth - art...@ar... ------------------------------------------------------------------------------ The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Oorexx-users mailing list Oor...@li... https://lists.sourceforge.net/lists/listinfo/oorexx-users |
From: Art H. <art...@ar...> - 2013-02-17 20:50:56
|
> Art > I use these for menues ( I always start with ..rc files, when all > is OK I copy to a second source (.rexx )) > > Script: > menubar = .scriptmenubar~new(self~dialogName".rc",IDR_MENU1) > menubar~attachto(self) > > Binary (.dll) > menubar = .binarymenubar~new(self~dialogName".dll",IDR_MENU1) > menubar~attachto(self) > > then it's just to replace scriptmenubar with binarymenubar and .rc > with .dll in new .rexx and then rexxc .rexx to .rex > > /hex > Good suggestion to use the ~attachto to avoid another change between the two versions. Thanks again for your help. > ------------------------- > Ursprungligt Meddelande: > Från: Art Heimsoth <art...@ar...> > Till: Open Object Rexx Users <oor...@li...> > Kopia: Datum: söndag, 17 februari 2013 19:51 > Ämne: Re: [Oorexx-users] Changing from RcDialog to ResDialog > >> Maybe a missing assignTo? >> >> Staffan >> > Mark's reply with the change needed to the .BinaryMenuBar is what > was needed. In reading further in 24.2.1 I now see where there are > multiple ways of connecting events to the menu bar, and not all > ways work the same for RcDialog as for ResDialog. I am off again > to find the next difference, as not all of my dialogs are working > correctly yet. Thanks all for your pointers and help. > > -- > Art Heimsoth - art...@ar... > |
From: Art H. <art...@ar...> - 2013-02-17 22:53:19
|
> Art > I use these for menues ( I always start with ..rc files, when all > is OK I copy to a second source (.rexx )) > > Script: > menubar = .scriptmenubar~new(self~dialogName".rc",IDR_MENU1) > menubar~attachto(self) > > Binary (.dll) > menubar = .binarymenubar~new(self~dialogName".dll",IDR_MENU1) > menubar~attachto(self) > > then it's just to replace scriptmenubar with binarymenubar and .rc > with .dll in new .rexx and then rexxc .rexx to .rex > > /hex I tried removing the ending parameters after the id on the .binarymenubar and then adding the menubar~attachTo(self) but I get an error on that statement indicating menubar does not understand the message ATTACHTO. I have the dll full name instead of the self~dialogName that you showed, but did not think that should matter. Using trace shows that the .BinaryMenuBar~new works okay and returns "a BinaryMenuBar" value. Comments? > ------------------------- > Ursprungligt Meddelande: > Från: Art Heimsoth <art...@ar...> > Till: Open Object Rexx Users <oor...@li...> > Kopia: Datum: söndag, 17 februari 2013 19:51 > Ämne: Re: [Oorexx-users] Changing from RcDialog to ResDialog > >> Maybe a missing assignTo? >> >> Staffan >> > Mark's reply with the change needed to the .BinaryMenuBar is what > was needed. In reading further in 24.2.1 I now see where there are > multiple ways of connecting events to the menu bar, and not all > ways work the same for RcDialog as for ResDialog. I am off again > to find the next difference, as not all of my dialogs are working > correctly yet. Thanks all for your pointers and help. > > -- > Art Heimsoth - art...@ar... > |
From: hakan <he...@us...> - 2013-02-18 05:35:56
|
1 comment here, self~dialogname is a variable/attribute set by me and not by ooDialog /hex ------------------------- Ursprungligt Meddelande: Från: Art Heimsoth <art...@ar...> Till: he...@us..., Open Object Rexx Users <oor...@li...> Kopia: Datum: söndag, 17 februari 2013 23:53 Ämne: Re: [Oorexx-users] Changing from RcDialog to ResDialog > Art > I use these for menues ( I always start with ..rc files, when all > is OK I copy to a second source (.rexx )) > > Script: > menubar = .scriptmenubar~new(self~dialogName".rc",IDR_MENU1) > menubar~attachto(self) > > Binary (.dll) > menubar = .binarymenubar~new(self~dialogName".dll",IDR_MENU1) > menubar~attachto(self) > > then it's just to replace scriptmenubar with binarymenubar and .rc > with .dll in new .rexx and then rexxc .rexx to .rex > > /hex I tried removing the ending parameters after the id on the .binarymenubar and then adding the menubar~attachTo(self) but I get an error on that statement indicating menubar does not understand the message ATTACHTO. I have the dll full name instead of the self~dialogName that you showed, but did not think that should matter. Using trace shows that the .BinaryMenuBar~new works okay and returns "a BinaryMenuBar" value. Comments? > ------------------------- > Ursprungligt Meddelande: > Från: Art Heimsoth <art...@ar...> > Till: Open Object Rexx Users <oor...@li...> > Kopia: Datum: söndag, 17 februari 2013 19:51 > Ämne: Re: [Oorexx-users] Changing from RcDialog to ResDialog > >> Maybe a missing assignTo? >> >> Staffan >> > Mark's reply with the change needed to the .BinaryMenuBar is what > was needed. In reading further in 24.2.1 I now see where there are > multiple ways of connecting events to the menu bar, and not all > ways work the same for RcDialog as for ResDialog. I am off again > to find the next difference, as not all of my dialogs are working > correctly yet. Thanks all for your pointers and help. > > -- > Art Heimsoth - art...@ar... > |
From: Mark M. <mie...@gm...> - 2013-02-17 23:20:58
|
On Sun, Feb 17, 2013 at 2:53 PM, Art Heimsoth <art...@ar...>wrote: > > I tried removing the ending parameters after the id on the .binarymenubar > and then adding the menubar~attachTo(self) but I get an error on that > statement indicating menubar does not understand the message ATTACHTO. > I have the dll full name instead of the self~dialogName that you showed, > but > did not think that should matter. Using trace shows that the > .BinaryMenuBar~new > works okay and returns "a BinaryMenuBar" value. Comments? > Art, Doesn't seem right. Can you show your lines of code and the exact message you are getting. Not the trace output please just the code and the syntax error message. -- Mark Miesfeld |