saving bug?

Comments (11)

Posted 11 years ago by Luke Burt

to add a few updates:

Seems to only affect local resources linked to within the html (external css had to be resaved under this app for it to load the css - images /objects however will not load)

Linking to an image on the web was fine, but as soon as it's linked to a local file it breaks?

saving in notepad under the same file after being broken by metro apps doesnt fix it, resaving as a new file does, however fix it.

it's a really odd and frustrating problem nonetheless

Posted 11 years ago by Actipro Software Support - Cleveland, OH, USA

Hi Luke,

That's really odd, we haven't seen that sort of thing happen at all. Every time we have saved files, it's been spot on.

I can say that our code is using the standard asynchronous I/O routines in WinRT that Microsoft makes available to us, which is likely the same code that other editor apps use too. Specifically we use the "IStorageFile.OpenStreamForWriteAsync()" method. It shouldn't really matter what types of files are being saved. To us, it's all just a text file that we write out with the method above. There isn't any special processing happening for CSS, etc. (at least on our end) when the save occurs.

If you are experiencing problems in all the editor apps, then you might be best off posing your question over in the Microsoft forums since perhaps someone there has heard of this happening. You should remember that the file I/O in Windows 8 apps is all async too. If you are saving to a networked drive (like SkyDrive or Box) then maybe something isn't finishing up correctly or in time (before the app shuts down) during that save process? You could try saving to your local drive (if you aren't already) and see if that makes a difference.

Another thing I just thought of was perhaps something else is locking the file and preventing it from saving? You mention that it's generally files that are linked to by something else. So maybe a web browser or something else you are running is preventing the file from saving. It's hard to say, just a thought.

[Modified 11 years ago]

Actipro Software Support

Posted 11 years ago by Geoffrey

I am having the exact same issue.

I make 2 copies of the same HTML file in my local Documents directory
Both files open and display normally in IE
Open, then save one of the files using Code Writer, making no changes
The html saved by Code Writer no longer displays correctly in IE. Only the most basic text formatting displays.

I can diff or binary compare the two files and they are identical. Veiwing source within IE looks identical. If I copy the problem file to a new file, the issue goes away. I've checked all file attributes that I can think of and everything looks the same.

Modifying the html with Notepad and saving does not cause a problem.

Posted 11 years ago by Actipro Software Support - Cleveland, OH, USA

Hi Geoffrey,

As mentioned above, we use the standard WinRT I/O routines to save files, so instead of comparing to Notepad, I would ask that you see if you get the same results in another Windows Store editor app. Luke seemed to find that all of them had the same issue, meaning that it's likely some issue core to WinRT itself.

We tried to repro this but still haven't been able to. Can you give very exact steps to do so, including links to any files that you are opening, etc. so that we can try and get it to happen on our side?

Thanks!

Actipro Software Support

Posted 11 years ago by Geoffrey

I haven't had much time to look at this the last few days, but I've discovered a bit more and the problem is related the character encoding being used to save the html file. I can 'fix' the Code Writer saved html file in Windows Notepad by doing "Save As" and selecting Unicode or UTF-8. Saving as ANSI in Notepad works as well - as long as the file was not already 'damaged' by Code Writer. By 'fix' or 'damaged' above, I simply mean whether the htlm+css is rendered as expected by IE 11.

Also, I was trying to do this using a Surface Pro 2, not RT and haven't got another "metro" text editor. The logical thing to do would be just use a desktop editor, but I'm curious if this particular problem is IE being too finicky, Code Writer not properly handling character encoding, or a Windows 8.1 New UI weakness... Or all three.

simple.html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Test Page</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<link href="css/test.css" rel="stylesheet" type="text/css">
</head>
<body>
<h1>Heading 1 Red/Small</h1>
<h2>Heading 2 Green/Medium</h2>
<h3>Heading 3 Blue/Large</h3>
</body>
</html>

test.css

/* test.css */

body{
background-color: #FFFFDD;
}

h1 {
font-size: 10pt;
color: Red;
}

h2 {
font-size: 15pt;
color: Green;
}

h3 {
font-size: 20pt;
color: Blue;
}

Posted 11 years ago by Actipro Software Support - Cleveland, OH, USA

Hi Geoffrey,

Thanks for the sample files. I tried opening them both in Code Writer, and then opening the HTML in IE. I was able to make changes to the files fine and see them update in IE ok. Please give exact steps, start to finish, on how you repro it with these two files. And let us know if you are using the Metro IE or desktop.

Also if you think this might be some encoding issue, Code Writer lets you select the default encoding in settings and you also can modify it on a document by document basis. You shouldn't really compare a desktop app to Code Writer though if trying to narrow down whether it's a Code Writer bug or a WinRT bug. You really should try another metro editor app and see if the same thing happens when following your process there.

Actipro Software Support

Posted 11 years ago by Jeff Krans

I have the exact same problem. I used Geoffrey's code from above and opened the html file in IE on my Surface RT and the styles initially displayed as expected. I then opened the html file in Code Writer and without making any changes, simply clicked save. After exiting out of the app and then attempting to open the html file once again in IE, the styles are lost and ignored by the browser. So far, I've experienced this same behavior with all of my html/css files. Along with the styling, image files are also ignored by the browser. This problem isn't specific to Code Writer however, as I've tested this same process with other editors such as Notepad RT and experience the same results. This leads me to believe its an IE/system setting somewhere with the Surface.

I've tried a number of different settings etc, but have had no success. Not exactly sure where to go at this point.

Thanks,
Jeff

Posted 11 years ago by Actipro Software Support - Cleveland, OH, USA

Hi Jeff,

Hmmm... I'm not really sure what it could (we haven't been able to repro it yet, even on Surface Pro with IE) be but based on yours and others findings that it happens with all Windows Store editor apps, it seems like a bug in IE. I would recommend contacting Microsoft on this via their IE and/or general WinRT platform product support. It sounds like something on their end is going wrong.

I know you can't test this on Surface RT, but those with a Surface Pro, I'd be interested to know what happens if you have an editor like Code Writer working with files and then open the files in something like desktop Chrome instead. I'm curious if the same issue happens there or not with similar repro steps (but excluding IE of course).

Actipro Software Support

Posted 11 years ago by Actipro Software Support - Cleveland, OH, USA

Hi All,

I'm not sure if the problem mentioned in this other file save thread is related, but it might be. Our file save routines basically go down one of two paths based on what character encoding option you have selected in the Settings:

Automatic detection character encoding - A simple one-line method provided by Microsoft is used to save the file.
Other character encoding - Another method where we write out to a stream that uses the encoding. However while researching the bug mentioned in the other thread we found that the main method Microsoft provides here for writing won't clear old contents of the file before the file write starts. Thus if the saved text is smaller than the file's length, some old characters would remain at the end. We found a workaround for this problem and have it ready to go for the next version.

I'm curious if you think the fix we just did for #2 might apply to the problems described in this thread or not.

Actipro Software Support

Posted 11 years ago by Geoffrey

I'm not willing to put much more into this, but if I notice there has been an update I'll give it a try and post here whether my IE/CSS issue still exists. My current CW version: 2.2

Posted 11 years ago by Jeff Krans

Hey guys, thanks for following up. Not sure if the character encoding issue is related or if the slated fix will correct the problem, but I'm anxious to try. I'm on CW version 2.2 as well.

Jeff

The latest build of this product (v4.2.42) was released 4 years ago, which was after the last post in this thread.

Comments (11)

Add Comment