HTML Logo by World Wide Web Consortium (www.w3.org). Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS, which is now in beta. ocPortal 9 will be superseded by Composr 10.

Head over to compo.sr for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.


Wiki+ tree:- missing child-page issue.

Login / Search

 [ Join | More ]
 Add topic 
Posted
Rating:
#101522 (In Topic #19912)
Avatar

Well-settled

Greetings,

After three years of developing various CMSs as candidate platforms for my rather complex interactive site, and wondering all along whether I shouldn't be focusing on ocPortal, I finally took the plunge about a month ago. Within my first two days I knew it 's the system I've been looking for, and have been since then thoroughly enjoying myself discovering and tweaking everything it has to offer. OCP is a simply fantastic achievement - hats off and boundless gratitude to all its core team! I'm smitten...

In other words, I'm a true newbie with it, yet another newbie with a fast-growing bunch of newbie-type questions! In no particular order, this is the one I'd like to ask in my very first post (after a couple of hours of unsuccessful topic-searching):

Currently I'm customizing Wiki+, which will be absolutely pivotal to my site. I don't know if this is common problem, or how straightforward it might be, but here it is: I've successfully created a few wiki pages, one as the top-level parent, and the others its children. No problems using the  Wiki+ Tree Editor for setting up the relationships, which display as expected both at the end of the parent page and in the Wiki+ Page Editor screens. However, in the Wiki+ Tree, the first of the children (labelled Id2, with the wiki home page as Id1) will not display, regardless of whether I make it the sole child or group it with other combinations of children. Can anyone help me with this one?

My hunch is that it may be database related. Originally I mis-titled the page in question and needed to correct my mistake in my mSQL database, which seemed to work without a hitch. I couldn't find a way to get ocP to rename it - which is the reason I'm posting this question. My concern is that my community wiki contributors may now and then, like myself, misname a page they created, which will make it invisible to anyone using the tree to browse/navigate through the overall wiki. Of course, they could just copy the entire comcode into a newly created, correctly titled wiki page and then delete the "dud", but that's rather messy, I think, and I'm sure my users won't appreciate having to resort to that one bit. But maybe the problem is down to something quite different that I've so far missed?

Thanks for reading this, and in anticipation of all replies!

Back to the top
 
Posted
Rating:
#101561
Avatar

Hi RichT,

Welcome to ocPortal :). Glad you like it.

Sorry for the delay in reply, I had a few things to catch up with.

However, in the Wiki+ Tree, the first of the children (labelled Id2, with the wiki home page as Id1) will not display, regardless of whether I make it the sole child or group it with other combinations of children. Can anyone help me with this one?

I think this probably has something to do with how we allow pages to have different names for different tree positions. My suspicion is you were able to rename, but somehow it ended up as a dead reference.

I'm taking a look to see if I can reproduce and will then see if we can make things clearer.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#101562
Avatar

Hmm, okay…

I intentionally broke an ID reference when I re-edited the tree, and it dumped out all the children as orphans. I guess our error-checking code is not very forgiving here.

Generally though, I don't think our interface is great here. I have refined it over the years, so it gets better, but it still is a bit clunky.

I'll make some changes and put out as a hotfix.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Important!
Posted
Rating:
#101565
Avatar

Automated fix message

RichT said

Greetings,

After three years of developing various CMSs as candidate platforms for my rather complex interactive site, and wondering all along whether I shouldn't be focusing on ocPortal, I finally took the plunge about a month ago. Within my first two days I knew it 's the system I've been looking for, and have been since then thoroughly enjoying myself discovering and tweaking everything it has to offer. OCP is a simply fantastic achievement - hats off and boundless gratitude to all its core team! I'm smitten...

In other words, I'm a true newbie with it, yet another newbie with a fast-growing bunch of newbie-type questions! In no particular order, this is the one I'd like to ask in my very first post (after a couple of hours of unsuccessful topic-searching):

Currently I'm customizing Wiki+, which will be absolutely pivotal to my site. I don't know if this is common problem, or how straightforward it might be, but here it is: I've successfully created a few wiki pages, one as the top-level parent, and the others its children. No problems using the  Wiki+ Tree Editor for setting up the relationships, which display as expected both at the end of the parent page and in the Wiki+ Page Editor screens. However, in the Wiki+ Tree, the first of the children (labelled Id2, with the wiki home page as Id1) will not display, regardless of whether I make it the sole child or group it with other combinations of children. Can anyone help me with this one?

My hunch is that it may be database related. Originally I mis-titled the page in question and needed to correct my mistake in my mSQL database, which seemed to work without a hitch. I couldn't find a way to get ocP to rename it - which is the reason I'm posting this question. My concern is that my community wiki contributors may now and then, like myself, misname a page they created, which will make it invisible to anyone using the tree to browse/navigate through the overall wiki. Of course, they could just copy the entire comcode into a newly created, correctly titled wiki page and then delete the "dud", but that's rather messy, I think, and I'm sure my users won't appreciate having to resort to that one bit. But maybe the problem is down to something quite different that I've so far missed?

Thanks for reading this, and in anticipation of all replies!

This issue has been filed on the tracker as issue #1490, with a fix.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Important!
 
Posted
Rating:
#101588
Avatar

Well-settled

Thank you, Chris, for looking into this so thoroughly, and for your time and effort spent on producing the hotfix.

I've now replaced the original 3 files with the hotfix versions, seemingly without mishap. You're quite right about the ! operator - the = invites no puzzlement at all over what is meant. However. the behaviour I reported remains unchanged in respect of the maverick page - despite rechanging its name - both its title and in the Tree Edit Screen, and these changes being correctly displayed everywhere subsequently, the Tree-page itself still doesn't recognize its existence. Seems strange that it unquestionably has an ID tagged to it and yet, unlike its siblings (it's not getting orphaned), doesn't pass its particular value to the Tree's input function.

That apart, your hotfix has solved the original problem of not being able to re-name the page once it had been saved - which is what necessitated my doing so within my database. That's quite a relief, I must tell you.

I guess what I should do next, when I have a few minutes, is try exactly replicating the steps I took with re-naming the problematic wiki page at db table level, using a different one. I'll let you know what transpires.

I've a confession to make - immediately upon unzipping your .tar file, I uploaded one of its files back into your tracker system by mistake. It's not sitting there for your attention and is simply an identical copy of your original that's of no use whatever to you. I do most sincerely apologize for that!

Thanks once again, regards and a very prosperous New Year to you!

Richard





 


Back to the top
 
Posted
Rating:
#101589
Avatar

Hi Richard,

If you'd like me to look directly onto your site, you can open a private free bug report ticket:

https://ocportal.com/site/tickets/ticket.htm?ticket_template=bug&cost=free

We'd need FTP access details (or equivalent access).

Regards,
Chris


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#101609
Avatar

I've re-read what you wrote, and I now see you're referring to the Wiki+ tree screen. Before I was thinking about the edit tree screen and view page screen.

Okay, I can see two possibilities:
  1. If the page does not allow guest access, it won't show on the tree. That's a limitation of the current system, it's to do with how the caching works. You can easily assign guest access to the page though; most users won't have a use for this (instead will just make the whole Wiki+ private if they want).
  2. If a page is a child of more than one parent (I know, weird terminology) it will only show under the first one in the tree. This is to stop repetition and potentially loops.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#101625
Avatar

Well-settled

Many thanks for your last two posts, Chris!

The latter, I'm delighted to report, pinpointed the cause of, and entirely solved, my problem. The page in question was indeed without Guest-level viewing-access, as you figured it might possibly be.

I confess I do recall reading about this a while back - and sort of misinterpreting what was implied by it. Not wanting non-subscribing visitors to have access to the site's Wiki pages, I'd  removed the Guest-level access from it, since it is a genuine wiki entry. The other "children" I'd created are all dummies for testing-purposes, and as such I'd not bothered to remove the Guest access perm - and likewise the Wiki Home page. Hence, obviously, these appeared on the Tree.

Since I wish registered non-subscribers the ability to see a list of what's inside the Wiki, as an incentive to subscribe, I reckon my way forward will be to edit  the default Site Wiki side-menu so that only the Home page and Tree branches are visible to them,  and such that the links on those pages are blocked by a match-key parameter inserted into the Wiki_Screen template to prevent the destination pages from opening. Does that sound roughly right to you? (For some reason my attempts to prevent page access via the Permissions Tree system have so far failed.)

All told, it looks like my o.p. was a double issue, neither, thankfully, database-related. I'm immensely grateful for all your trouble pursuing it - not only because both are now fixed, but especially since, through exploring the two issues side-by-side, I've learned volumes about ocP's access/permissions system and its potential for providing - unlike the other CMSs I've wasted time on - exactly the versatillty and detailed granularity required for my site's structural demands. All thanks to the vision of its creators to develop a user-programmable software with a sufficiently high-level language for non-geeks to understand how to tweak it themselves in accord with their own vision. And why ever not, for goodness sake?

Regards and best wishes for now,

Richard.



Back to the top
 
Posted
Rating:
#101626
Avatar

Hi,

It should be a bit simpler than that.

For some reason my attempts to prevent page access via the Permissions Tree system have so far failed

This should work. It should just be a case of removing Guest view permissions on Site\cedi in the Permission Tree Editor.


Maybe there is some confusion here. "cedi" is the original name for this system, it was only recently renamed to Wiki+, but we haven't updated all the page names yet (that will happen in v10).


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#101638
Avatar

Well-settled

Hi Chris and thanks for these comments!

Regarding the names "Wiki+" "cedi" (and "seedy", for that matter) - no confusion on my part there; I've always understood these to be perfect synonyms. (And the cedi.ini definitions make this explicit, of course)

As for preventing viewing access to the wiki-pages via the Permissions Tree Editor, yes, initially that seemed to me the obvious method to apply - simply remove viewing access to Site:cedi for my "Registered Guests" usergroup. In actuality I first removed access to the specific wiki-page in question - to no effect. Then I removed access to the tree page(s) (2 are listed: "HTML:cedi_tree_made" and "HTML:cedi_tree_made1") - again to no effect. Finally I took your measure of removing access to the entire Module:cedi - still to no effect! None of these steps has disabled the displaying/active status either of i) the branches on the Site zone Wiki+ side-menu, or ii) the Wiki Tree and its links, or iii) the destination wiki pages. In other words, everything is still working just as if no permissions had been removed. The only impact is that the "Edit" and "Edit Tree" links at the foot of wiki pages no longer display.

Additionally, removing permission for displaying the side-menu branches to this usergroup via the Menu Management page (i.e., ticking the box "display only if has permission") is having no impact.

Hence my idea of creating a match-key (an unmatchable one) as a workaround for preventing the wiki page screen from opening when links on the Tree are clicked. Making the match-key relate to the Wiki_Page_Screen.tpl rather than to individual wiki pages would, I imagine, abolish my needing to set up a specific match-key every time a user submitted a new wiki page.

Incidentally, I'm experiencing exactly the same lack of success in removing the Zone Menu link to the Content Management zone for my Registered Guest usergroup. Despite having disabled the entire Zone  and every one of its modules and pages, registered guests still see the menu link, can access the CMS homepage, and make use of its full set of facilities. The only way I've succeeded has been to define an unmatchable match-key in the Menu Management section, in respect of the Content Management branch of the Zone menu. This isn't ideal - firstly, my match-key generates an error message (namely, the parameter … was referenced by the template but not passed) visible to all usergroups (predictable, since I haven't initialized the said parameter in the template concerned); secondly, for some reason I haven't yet fathomed, it interferes with my global.css rules relating to how the zone menu's displayed links are styled. Weird.

To be honest, on the subject of match-keys. I'm still a bit confused about how to define them and apply them via the Security > Match-key page restrictions page fields. For me, there isn't enough guidance on the page about this - a made-up example or two could really help, and/or a schematic model of the general syntax. It would be great, too, if some more generalizable statement such as display="0" or =false could alternatively be applied as an argument (I'm presuming there isn't, and that ocP's language doesn't allow for that) - but that's just me.

In case you're wondering, my ocP version is 9.0.9. Two things I'd like to ask regarding that: first, on reading the tutorial on permissions, I noted a couple of editing-features that don't appear on my admin menus. I'm guessing they've been omitted from recent versions and the tutorial dates from when they were current, yes? Secondly, would it perhaps help - and indeed resolve - my present issue if I were to upgrade?

I'm also thinking that the course of our exchanged posts has progressed well beyond the terms and scope of my o.p. and that it might be more of service to other forum visitors if I were to open a new topic,  specifically about controlling ACL permissions for the Wiki+ tree. I'll most happily do so if you're thinking likewise! Please let me know.

Thanks for reading, and best regards,

Richard


  

Back to the top
 
Posted
Rating:
#101639
Avatar

"Registered Guests" usergroup

The member you're testing with, are they in just this usergroup? If they're in more than one group, the permissions of the other group(s) would be available to them too.

(Match keys)

These are one of our most complex features, I wouldn't expect many users to use them.

on reading the tutorial on permissions, I noted a couple of editing-features that don't appear on my admin menus. I'm guessing they've been omitted from recent versions and the tutorial dates from when they were current, yes?

It could be out of date, but we haven't been removing features. What is missing? Probably we moved something.

Secondly, would it perhaps help - and indeed resolve - my present issue if I were to upgrade?

I don't think so, no permission issues fixed recently as far as I recall.

If it's not an issue with your test member being in more than one group, you can open a bug report as indicated earlier and someone on my end (probably me ;)) will be happy to take a look.

I'm also thinking that the course of our exchanged posts has progressed well beyond the terms and scope of my o.p. and that it might be more of service to other forum visitors if I were to open a new topic,  specifically about controlling ACL permissions for the Wiki+ tree. I'll most happily do so if you're thinking likewise! Please let me know.

I wouldn't worry about it :).


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#101646
Avatar

Well-settled

Eureka! Chris, you were absolutely correct in suspecting my test Registered User as belonging to a secondary usergroup ("Members", a higher level group with modest permissions to view and manage site content). Having now removed "him" from this secondary usergroup, all aspects of my intended setup for Registered Users (including the Wiki tree and pages) are working perfectly. Thanks no end!

I'm kicking myself somewhat for not having thought to investigate my test user's usergroup profile, believing that my settings specify newly joined users should be assigned to the Registered Guests group and to no secondary group. I've just thoroughly checked my settings for each one of my usergroups, and from what I can see, that is exactly the outcome I'd expect. All my usergroups are configured independently of each other (i.e. without inherited permissions and privileges) and none is set up to include automatic assignment to a secondary usergroup.

Nevertheless, since checking all this, I've joined up another dummy Registered Guest, and this one, like my first, was automatically assigned with secondary membership of my "Members" group (and, of course, granted the ACL perms of that group). I really can't believe there could be any unreported bugs relating to so basic a matter as this, so I reckon there must (again!) be something I'm overlooking or doing wrong in my settings that causes the automatic secondary usergroup assigning. Might this be due to a Global Privileges setting I'm not taking into account?

Can anyone enlighten me please?

Thanks for reading!

Richard
Back to the top
 
Posted
Rating:
#101647
Avatar

Hi,

Can you attach screenshots of the edit forms for both Members and Registered Guests.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Back to the top
 
Posted
Rating:
#101650
Avatar

Well-settled

Hi Chris,

As you most kindly requested, here are screenshots of my settings for usergroups "Registered Guests" and "Members"

Usergroups Summary.jpg
Registered Guests 01.jpg
Registered Guests 02.jpg
Member 01.jpg
Member 02.jpg
Common Settings 01.jpg
Common Settings 02.jpg

Kind regards,

Richard

Back to the top
 
Important!
Posted
Rating:
#101665
Avatar

Automated fix message

RichT said

Eureka! Chris, you were absolutely correct in suspecting my test Registered User as belonging to a secondary usergroup ("Members", a higher level group with modest permissions to view and manage site content). Having now removed "him" from this secondary usergroup, all aspects of my intended setup for Registered Users (including the Wiki tree and pages) are working perfectly. Thanks no end!

I'm kicking myself somewhat for not having thought to investigate my test user's usergroup profile, believing that my settings specify newly joined users should be assigned to the Registered Guests group and to no secondary group. I've just thoroughly checked my settings for each one of my usergroups, and from what I can see, that is exactly the outcome I'd expect. All my usergroups are configured independently of each other (i.e. without inherited permissions and privileges) and none is set up to include automatic assignment to a secondary usergroup.

Nevertheless, since checking all this, I've joined up another dummy Registered Guest, and this one, like my first, was automatically assigned with secondary membership of my "Members" group (and, of course, granted the ACL perms of that group). I really can't believe there could be any unreported bugs relating to so basic a matter as this, so I reckon there must (again!) be something I'm overlooking or doing wrong in my settings that causes the automatic secondary usergroup assigning. Might this be due to a Global Privileges setting I'm not taking into account?

Can anyone enlighten me please?

Thanks for reading!

Richard
This issue has been filed on the tracker as issue #1508, with a fix.


Become a fan of ocPortal on Facebook or add me as a friend. Add me on on Twitter.
Was I helpful?
  • If not, please let us know how we can do better (please try and propose any bigger ideas in such a way that they are fundable and scalable).
  • If so, please let others know about ocPortal whenever you see the opportunity.
  • If my reply is too Vulcan or expressed too much in business-strategy terms, and not particularly personal, I apologise. As a company & project maintainer, time is very limited to me, so usually when I write a reply I try and make it generic advice to all readers. I'm also naturally a joined-up thinker, so I always express my thoughts in combined business and technical terms. I recognise not everyone likes that, don't let my Vulcan-thinking stop you enjoying ocPortal on fun personal projects.
  • If my response can inspire a community tutorial, that's a great way of giving back to the project as a user.
Important!
 
Posted
Rating:
#101674
Avatar

Well-settled

Hi Chris!

Thanks for doing that fix - I'm delighted to report my registration process is now working as intended. It's also really good to see that dummy Registered Guests are now being sent an email for validating their account, which they weren't before installing the fix, despite my having opted for that, and moreover, site-activity notification emails are now reaching my email client inbox as desired. (Hitherto, users were automatically being logged in directly upon submitting the personal details form.)

Your hotfix, I'm glad to say, exposed the fault that was preventing the sending of these system emails. Initially, after installing its files, ocP bailed out due to a mail.php error after submitting the joining user's personal details form (and after these had been added correctly to their primary usergroup). I'd configured email sending to use SMTP; disabling it in favour of PHP sending has resolved this entirely, so far as I can ascertain at present. Whether opting for SMTP was in any way connected with my issue with automatic secondary usergroup registering seems in no way self-explanatory to me, but perhaps the connection makes good sense to you! Anyhow, no matter: Problem solved!

Thanks over and over for all your help wading through this for me, Chris -

Best regards, 

Richard


Back to the top
 
1 guests and 0 members have just viewed this: None
Control functions:

Quick reply   Contract

Your name:
Your message: