|
Poznámky k chybe |
ajh
2005-01-28 14:08
|
1. Please could you ensure that you are using the latest version of the htmlcal extension with the latest version of the CVS PME. You can find the latest version of htmlcal on bug report #297. In particular, make sure you use the latest version of the PME setup program to generate your style commands - earlier versions generated style commands that interfered with the htmlarea css (and this was one of the symptoms).
2. If you still have the problem after trying this, please could you attach a database schema and PME config that will let me reproduce the problem and I'll try and fix.
edited on: 2005-01-28 14:10
edited on: 2005-01-28 14:11 |
|
|
lemmi
2005-01-30 02:54
|
ajh,
After some hours trying I gave up. Using the latest CVS version of the core class and the extension provided in #297, it will do all the nice things I appreciate to have phpMyEdit, but it will not start any htmlarea 3.0. My present applications are still running with core #147 and a modified htmlcal extension. Several text areas in html mode are no problem (except I put it on tab pages). But the most recent extension doesn't work at all. If I compare the code output of the phpMyEdit script with the code of the example pages of htmlarea concerning initializing the editor then I would conclude that there is missing a lot.
Thus, do you have really run succesfully an application using the extension you recommend?
If so, please let me know your approach. |
|
|
ajh
2005-01-30 15:36
|
I've certainly tested this for both calendar popups and htmlareas, so I don't believe that there's any fundamental problems with the extension. It could be a problem with the tabs feature though. Please could you attach your database schema and your PME configuration script to this bug report and I'll have a look at the problem.
Normally if it doesn't start the htmlarea field, it is because it can't find the javascripts.
edited on: 2005-01-30 15:36 |
|
|
lemmi
2005-02-01 19:40
|
I spent some more time testing the whole stuff. I found a bug in my script concerning the javascript location. Now it works as the older version, that means the html textarea on the open tab opens without problems, the areas on the second tab pane are still collapsed.
I have attached the myEdit script (including css an required images), the database with an empty record and the htmlcal extension I use (it has only a small modification for the calendar module).
The myEdit script is a very simple application to manage some news on our intranet.
I really hope you will find the reason. I have also added the error log recorded by the JavaSript console of Firefox. |
|
|
ajh
2005-02-01 21:09
|
Unless I'm being really dim, I can't see the database file. Would you mind just exporting the schema as an SQL CREATE TABLE command so I can reproduce it.
BTW - have you tried this without using your stylesheet? I'd be surprised if it made a difference, but it's worth checking. |
|
|
ajh
2005-02-01 22:54
|
Forget the database file - I can reproduce the problem myself. It looks to me like a really nasty interaction between the javascript for the tabs and the javascript for HTMLarea, and I'm not sure whether I can fix it. I need to spend more time looking at it, but I'm not hopeful at the moment.
BTW - at this stage I don't think that any html fields will work on anything but the initial page of a tabbed form.
Update...I know what the problem is, but I haven't found a reliable way of fixing it yet. It is all todo with some nasty interactions going on with the way that the DHTML works for the tabs and the way that it works for HTMLarea. Basically if the field is not visible when HTMLarea attaches itself to it then it assumes that the field is zero height - thus the problem. The answer is code it so that all of the tabs are visible very briefly and then hide the appropriate ones. However there are still some real oddities going on that I don't understand. If anyone out there is a DHTML wiz then I could do with some help!!
edited on: 2005-02-01 23:37 |
|
|
hbernard
2005-02-02 06:45
|
Well, it seems like a bug in HTMLAREA, no ? Or, the HTMLAREA can't compute it's size and dhtml stuff _at all_ when attach-ing widget is hidden ?
I wrote the tab code but I don't use at all the Htmlarea...
* A workaround could be to hack the tab code to hide and display the HTMLAREA when displaying the tab, but this seems exensive (you have to walk through the list of the fields to know which ones are htmlarea-based)
* another trick could be simply to traverse the HTML tree and to mark visible all the tags when displaying the tab, but this will do nasty things when introducing subforms...
* or, is there a javascript call to force redraw to all instanciation of htmlarea class ?
Making tabs visible even a very short time is not usable, I think, it will flicker |
|
|
lemmi
2005-02-02 10:50
|
ajh, hbernard,
many thanks for spending so much time for my problem. But I guess that other users are also faced with this problem when using HTMLArea. At the moment there is no alternative html editor. The XStandard lite works fine, but is limited to Windows OS. Thus, solving the load problem of HTMLArea would be the preferred solution at the moment.
In the current implementation all html text areas are replaced on page load. Maybe the replace call should be triggered by the selected tab, i.e. the call to HTMLArea.replace(...) has to be moved to the tab handling javascript code. Then, HTMLArea will be initiated on the visible tab pane only. How do you think about?
(I added now the sql for create table I was forgotten yesterday)
edited on: 2005-02-02 10:53 |
|
|
ajh
2005-02-02 11:16
|
I'm pretty sure that this is solvable - it's going to be a matter of which order you do things in. Because HTMLarea can be used on arbitrary textarea fields, it has to use the current height in order to workout how big it needs to be. What I have managed to prove is that if you display all of the tab divisions initially, attach the HTMLarea to the fields and then hide them, it works fine. So I think that this is probably an issue of what order you do things in. So far I've removed the styles that set up the tabs initially and replaced them with some javascript that does the same thing after the HTMLarea.replace calls at the end. This almost works, but not quite. BTW - I haven't had any problems with flickering so far.
hbernard - I wouldn't say that this is a bug in HTMLarea, more like the way it was designed to work. I'm reluctant to try and change it as it seems to be the de facto standard for HTML editing and I want to be able to use future versions. |
|
|
hbernard
2005-02-03 21:13
|
ajh, I was not suggesting to dive into HTMLarea code ;-)
What about my question :
* or, is there a javascript call to force redraw to (all or one) instanciation of htmlarea class ?
And, How do you "display shortly" all the tabs ? With an onload handler ? I'm a bit reluctant to use this... |
|
|
ajh
2005-02-04 11:08
|
I've spent some time looking at the HTMLarea code and I think that I now understand why it doesn't work. HTMLarea dynamically reads the attributes of the textarea field when you attach to it, and modifies the DOM in order to add the extra buttons etc. For some reason, when the textarea is not visible, the attachment fails, because the DOM seems to be different.
Anyway - I think I know how to fix it...it will mean modifying the tab code so that when you select a tab, it does the HTMLarea.replace for the appropriate textarea fields at that time assuming they have not already been done. I think that can be done with a simple function call in the tab change function. PME will then need to write out an array of which htmlarea fields are in which tabs, and whether they have already been attached.
So I know what I will be doing this weekend :-)
hbernard - re your questions, unfortunately HTMLarea does not have a re-instatiation call. I've been trying to work out a way of telling whether an htmlarea.replace has already taken place from the DOM, but that is turning out to be too much like hard work! I think I'm just going to use a flag!
I did originally try leaving all of the tab divisions visible at the beginning by deleting the initial tab STYLE block and then setting the display properties in JavaScript after the HTMLarea.replace commands, but that didn't quite work.
edited on: 2005-02-04 11:11 |
|
|
lemmi
2005-02-04 11:56
|
ajh,
I'm happy to see that a solution will be in sight. It was also my first idea to initialize HTMLArea at the moment the tab pane opens (my post from 2-2-2005). Because I'm not such a JavaScript wiz I really appreciate your help. So, hopefully a not too busy weekend for you I'm looking forward on what you achieve.
Many Thanks. |
|
|
ajh
2005-02-07 09:56
|
lemmi - I'm afraid that I haven't finished the work - it is a larger rewrite then I had hoped, however on a positive note, I have prototyped an example HTML page with the new Javascript and it works - so I know that it can be done. The job I have to do now is to rewrite the extension so it generates the appropriate Javascript code for the code. Hopefully a couple more days. |
|
|
ajh
2005-02-08 15:04
|
OK - here it is! Hopefully this will work. I've tried it with both HTML and calendar fields on both tabbed and non-tabbed pages (and a combination of both) and it seems to work. I've also added in a feature to allow customer HTMLarea configurations. Instead of 'html'=>true you can now say 'html'=>'configname' and it will call the HTMLarea set up with that config (which you need to have created in your PME calling script.
Assuming this works, I'll get it loaded into the CVS |
|
|
lemmi
2005-02-08 17:55
|
ajh,
really good job you have done. I have tested it with my application and it works. So, the way to force the correct opening of HTMLArea is the right one. There is only one minor point remaining: If are more than one html text areas on the "hidden" tab, only the first one will be opened (at least in my application). Do you have tested such a configuration, too?
Best regards,
Gert |
|
|
ajh
2005-02-08 18:16
|
Stupid error number 1!!! Should be fixed now - try the .new version (removing the .new of course!) |
|
|
anonymous
2005-02-08 19:24
|
Yes, that was it! You are too fast. I found the bug too and as I intended to post a note I saw your reply. Thank you very much! Anyhow, in my opinion it's an important improvement of the htmlcal extension, and small cms could be simply realized by using pme.
By the way, who is an expert on the report extension? If you have virtual fields filled by joined table columns (e.g with 'sql'), the report shows the fields of the main table only and ignores any virtual field.
Is't a bug or a missing feature? |
|
|
lemmi
2005-02-08 19:27
|
Stupid, the above is my post, I forgot to login. |
|
|
lemmi
2005-02-09 09:49
|
ajh,
I found a second bug. It's due to the recently introduced feature of persistence of selected tab. You can reproduce the situation if you go into view mode and select the second tab and move then to the change mode by selecting the 'change button'. The htmlareas on the second tab pane opens as expected. If you now select the first tab, the iframes are collapsed (because htmlareas on the first tab pane are opened using the old approach). |
|
|
ajh
2005-02-09 11:01
|
I can't reproduce this problem. I've done what you suggested and it works fine. Basically I did a view, went to the second tab, went into change mode (all OK on the second tab), chose the first tab (all OK on the first tab).
The only only htmlareas that are now opened in the old way are those that are not in any tab at all - ie before the first tab definition. If you can supply a calling script and SQL schema I'll have a look at it. |
|
|
lemmi
2005-02-09 11:49
|
The problem occours if you have non-html fields prior to html fields and the first 'tab' definition is set in one of these non-html fields. At the moment the 'tab' option is set in the html field, it works. |
|
|
lemmi
2005-02-09 12:22
|
I must be more precise: The problem occours if you have set the first 'tab' definition in the f i r s t field, doesn't matter if it html or not. |
|
|
lemmi
2005-02-09 12:34
|
I added after line 374: $current_tab = $this->dhtml['prefix'].'tab'.$tab;
That's a hack that obviously works but I'm not sure about side effects. |
|
|
anonymous
2005-02-09 13:23
|
I encountered a new problem (even without the hack I made). After switching back to a tab that was already open, one can't get the focus of a html text area. The contents are still visible but there is no chance for editing. That's also in the add mode. Once switched to another tab and back, text can't be entered any more. |
|
|
ajh
2005-02-09 15:03
|
Which browser are you using? I can reproduce the problem in Firefox but it seems to work fine in IE...I'm beginning to wonder whether this is either an HTMLarea bug or more likely a Firefox bug.
By the way - your hack is spot on - it's actually a much better way of doing it and simpler for the javascript code. I've uploaded another cut of the code, it is now the .new2 file
edited on: 2005-02-09 15:15 |
|
|
lemmi
2005-02-09 15:17
|
Currently I'm using Firefox 1.0 |
|
|
ajh
2005-02-09 15:19
|
Hmmm... odder and odder. On Firefox if you go to one of the fields that isn't working, and then switch it to textmode and back again (click the "<>" button on the HTMLarea toolbar) it starts working again. |
|
|
lemmi
2005-02-09 16:04
|
Yes, sometimes it works, but sometimes not and once Firefox crashed as I tried to insert a table. I get the impression that the context to the different instances of HTMLArea is lost or at least mixed up. This could be a bug in HTMLArea, in the browser, or an initialization problem. In any case Firefox gives following javascript Error: el.tagName has no properties
Source File: http://localhost/myed/js/dhtmleditor/htmlarea.js
Line: 1986
And, have you ever tried to open the full-screen editor mode? Nothing is displayed but following Error: HTMLArea.I18N has no properties
Source File: http://localhost/myed/js/dhtmleditor/htmlarea.js
Line: 613 |
|
|
ajh
2005-02-09 18:54
|
I'm beginning to learn more than I ever wanted to know about HTMLarea! I think that there is some form of re-initialization that has to be done once the tab is switched to get Mozilla/Firefox to allow the field to be edited again. It looks to me as if the Mozilla edit mode gets switched off if the field is hidden - so it will need to be manually switched back on again. This is one area where Mozilla and IE are very different, so I guess it doesn't surprise me that it works in IE but not in FF. Oh well - more digging tonight. |
|
|
ajh
2005-02-10 14:00
|
Just to let you know...this problem seems to be caused by the interaction between HTMLArea and FF when the DIV containing the htmlarea field is hidden and re-displayed. I don't know that I would classify it as a bug, but it's certainly a behaviour that needs coding round.
This is a long way of saying that I'm not sure how easy this is going to be to fix! I'm beginning to think that the easiest way of doing it might be to try and remove the htmlarea editors from fields before they're hidden, and re-add them when they're redisplayed. The difficulty with this approach is that there is no way in the HTMLArea script of removing an htmlarea editor! I think that it is possible, but it means manually traversing the DOM to pull the offending content out.
I will carry on working on this, but I suspetc that it might take some time.
edited on: 2005-02-10 14:01 |
|
|
lemmi
2005-02-10 15:16
|
I agree that the whole story is quite suspect. Could we, perhaps, go a totally different way? I could imagine that a two-step editing for html text would be acceptable. What I have in mind is that in pme the html text(area) is only displayed, a textarea input field with an editor is not automatically engaged. Then we spent an extra button for each of these html text fields (attached to the individual fields). Clicking on these buttons will popup a new "clean" window with the particular textarea and the editor engaged. It's like the popup mode in HTMLArea. If the popup editor is closed, the contents of the pme textarea would be replaced by the new (or edited) content.
Maybe we could sail around all know (and unknown) cliffs because we have removed the editor from the pme environment. And, it gives us the possibility to step over to other editors (like the xstandard) with few modifications of the popup script only. How do you think about? |
|
|
ajh
2005-02-10 15:23
|
I hope that is not necessary. I think I now understand the way the HTMLArea attaches itself to the field, and I actually think that it would be quite easy to remove it. Let me experiment with this first.
Also - the current code still works well where you are not using tabs. |
|
|
ajh
2005-02-18 11:27
|
Hmmm...I've been following a discussion on the HTMLArea forum, and it looks to me as if it is being abandoned - too many problems with browser compatibility. My view is that what we have is good enough for PME, at least for IE and FF users. There are definitely bugs in HTMLArea, as I'm finding it necessary to code round some of them, but I am optimistic that we can get it working. |
|
|
ajh
2005-02-21 14:02
|
Okey-dokey...I now have the required fix. It will mean moving to Xinha (which is a fork of HTMLArea) which has some extra code in it to handle this problem. I have a prototype HTML page with tabs that works fine, I just need to recode the PHP to generate the correct Javascript. BTW - this is a Firefox bug - it should work fine with IE.
Hopefully I will have the new extension done by the end of the week. |
|
|
ajh
2005-02-23 11:11
|
I have uploaded the newest version of the extension (the .xinha version). To use this you must use the Xinha fork of HTMLArea - it will not work with the standard HTMLArea (which seems to be dead anyway). I believe that there is still a problem with it, especially with IE. For some reason, sometimes the htmlarea fields don't load first time, do a refresh and then they draw properly. I could do with some help trying to pin down when they draw and when they don't. It looks much more reliable using FF. The URL for Xinha is in the comments in the code.
I'm going to set up a thread in the forum to discuss this - so if you have feedback, please could you put it here: http://platon.sk/forum/projects/viewtopic.php?p=2286
edited on: 2005-02-23 11:20 |
|
|
ajh
2005-03-10 10:44
|
An update...I've pretty well given up trying to use HTMLArea or derivatives. There are too many bugs in FF/Mozilla which HTMLArea/Xinha does not code around. I am in the process of re-writing the extension to use TinyMCE (actually it is much, much simpler to implement) and have pretty well got it working. There is one bug in the TinyMCE code which needs patching to get it to work with PME tabs, but I hope that the new code will be finished in the next day or so. |
|
|
lemmi
2005-03-10 12:41
|
Hello ajh,
I was out for a certain time, and now I'm again working on that issue. What I made during my vacation was to look around what's available. I found two editors which seems to be a much better solution than HTMLArea or derivatives. One is TinyMCE and the other opne, and my favorite at the moment, the FCK (http://www.fckeditor.net). Do you know it? However, I haven't tried to implement it into PME but the available examples worked fine on IE and FF.
I hope that we will find a stable and good working solution with one of the two editors. My free time is limited at the moment, so I can't contribute to the issue in that speed you do it. |
|
|
ajh
2005-03-10 13:59
|
I've actually been looking at exactly the same two editors. FCK is more complicated to implement, and I have found a number of problems with it when using FF. TinyMCE seems to be much more stable - there is one problem I have found with FF but have been able to fix, so I think I've actually got a first version of the code working. It needs tidying up and documenting, but I should get it posted shortly. |
|
|
ajh
2005-04-20 23:28
|
OK - hopefully this is now resolved. I have switched to using TinyMCE (latest version of which fixes almost all outstanding problems and gives some important new functionality).
The new extension is called mce_cal and is now in the extensions directory of the CVS. This extension also incorporates the calendar popup functionality of the old calpopup extension. |
|
|
ajh
2005-04-28 20:31
|
Resolved by new extension called mce_cal now in the extensions directory of the CVS. This extension also incorporates the calendar popup functionality of the old calpopup extension. |
|
|
Prihlásiť
Registrácia
English
